Building a 21st century user interface, Part 1: Your app's competition... isn't who you think

Alpha geeks? They're so ... 1997

Web application programmers are a pretty egocentric lot, even if unintentionally. We (yes, I said "we") tend to assume that everyone is either like us, or intrinsically aspires to be like us. Ten years ago, we bought new cars off of all the work we got "future-proofing" apps for Y2K... often snorting into our hands as we dutifully converted our years to 4-digit formats. The poor masses were struggling to really grasp the crazy Internet and the apps we were building.

A decade later, though, the masses that worried about Y2K have risen up and taken over the Internet in very real ways. You can read your neighbor's blog, write on your mother-in-law's social networking site, and check out a long-lost cousin's family photos... all using Web apps built by the alpha-geeks of a decade ago. But here's the big problem: those users that are consuming all these apps aren't like Web programmers. These users have a different set of priorities, a different social identity, and entirely different expectations when they fire up Internet Explorer. (Yes, they're mostly IE users. Firefox? What's that?)

But why does any of this matter? It matters because as this consumer has become predominant, they have become savvy—not to the Web, but to what they like, and what they are annoyed by. A good Web app these days is at least as much user interface as it is functions. The ability to send someone a Christmas ornament through social networking sites is seen by this user as something just as relevant as the ability to recall a forgotten password. It takes a lot more than avoiding the blink tag to satisfy these users, too. They're not interested in our technical wisdom; they want intuitive, usable applications, and we have to deliver those apps, to an audience we don't always seem to understand very well.

So how do you serve an audience that's not that similar to you? Well, instead of trying to build some profile, with a name and occupation, you just need to understand what inputs these users have. What informs their likes and dislikes? Most important, what causes them to like—or hate—your particular Web app and user interface?

Today's Internet user is self-taught

First and foremost, today's Internet users—the consumers of your Web apps—are self-taught. They've figured out Web apps almost purely by intuition, and based only on what they already know about how things in their world work. So there's no computer science curriculum that causes them to wonder if that list of friends on their social networking site is stored as a static array or a linked list or a series of references to Friend objects.

Instead, users are simply clicking on what makes sense to them, based on the world outside of the Internet. Want to send a message to someone? There's no expectation of confirmation buttons and limitations on the keys available. You should be able to type in a message, add smileys and other little signature text pieces, click a single button, and you're done. Interested in buying a book? You should be able to "read" the back cover of the book, check out the book flap, see the cover art, and easily (and impulsively) drop the book in your cart and wander to the checkout line. Shipping estimates, tax, related titles, and so on, these are niceities, but aren't central to the desire of the user. The user just wants to make a quick purchase that models their experience in the real world.

And the teacher is new media

So then, what's the real world? What is informing the experience of the users that are either satisfied with your app, or are e-mailing your customer service team griping about how awful the app works? Well, there certainly aren't any computer science textbooks, and your users have never heard of Tim Berners-Lee or Jakob Nielsen. What they are experts in, though, is new media.

Ask the typical Facebook user what they do on a weeknight, and you'll almost certainly hear the words "TV," "TiVo," "YouTube," and a healthy smattering of "XBox" and "PlayStation." Throw in "texting" and "blogging" along with a lot of hanging out with friends and, of course, working late, and you've identified the big influences on how today's Internet user views the world, and your Web app.

But what does that actually mean? Well, first and foremost, it means you better have a DVD player and some form of TV programmer in your house if you want to build usable Web apps. Sound crazy? Check out the menu structure on TiVo, or the latest season of your favorite TV show on Blu-Ray DVD. If the interfaces for those products don't share anything with the navigation and organization of your Web site, you may have some real problems on your hands. Consumers are already paying for services like TiVo, DVD box sets, and the Metal Gear Solid 4 PlayStation 3 bundle. That means that your user finds value in these products.

And here's the thing: your app is free, at least for initial access. So if you want to get a user to spend money or time on your application, why not model it after things that you already know your user does find value in? In other words, as Web designers, we should take the body of knowledge that already feels good, worthwhile, and intuitive to users, and apply that body of knowledge to our applications. The result will be an experience for the self-taught user that "feels" valuable.

Your competition isn't another Web app

Today's Web designer has to face a pretty scary fact: they can't design for themselves, or even someone that's mostly like themselves. Instead, applications must be built based on the consumer, who comes loaded with expectation and pre-disposition. But those ideas aren't built upon other Internet apps. In fact, as a Web developer, you're no longer building apps that compete with other apps, at other URLs. You're competing with anything your user is willing to spend time on.

Here's just a partial list of your app's real competition:

• PlayStation 3, XBox 360, and Nintendo Wii games
• Lost, Battlestar Galactica, Survivor, CSI: Miami, and Scrubs
• Facebook, YouTube, and Twitter (yes, some alpha-geekery still abounds)
• AppleTV, NetFlix, Blockbuster, and every other physical and digital movie service
• iPhone, Blackberry, and Treo text messaging

With the exception of Facebook and YouTube, none of these are even online services! Even Twitter, which has a strong online component, is largely accessed through mobile phones. So no matter how great the user interface, you've got to understand what expectations your users come with that are not specific to the Web. What do they expect because of these competing services and products?

Back to top

Users want function and form

There's long been an argument about whether form or function is most valuable. Does beautiful design make function less important? Does a powerful working application easily trump a beautiful, less-useful one? This is a question that strikes at the heart of the usability discussion, because it involves design at two levels: function and aesthetics.

Before theorizing too much, though, it's worthwhile to look at your application's competition. What do Twitter, YouTube, Prince of Persia, and Lost do in these situations?

Function reigns supreme

Take even a passing look at the media applications and sources that are commanding attention (and revenue), and it's obvious: function is the key ingredient. Take a look at Twitter, which most closely resembles the Web apps you're probably building: all Twitter really has is function. You type in your status, and that status gets flung into the ether for all to see. The nicest user interface in the world for Twitter won't overcome the basic function—information dissemination—being unusable or unworkable.

When you look at the blockbuster television and movie competition, you'll find a pretty common element here, too: story. Whether it's Big Brother (which, astonishingly to me, has an almost home-video feel to 90% of the footage), Lost (and the host of serial-based shows that are similar), or CSI:, people are tuning in for characters. In the foregone days of mass-reading, the same was true: story is the functional component of fiction, and people are ultimately more interested in story than special effects or an amazing graphic leading out to commercial-land.

Our users are hungry to get something done. That "something" might be buying a leather jacket or viewing the available sizes on a set of new tires or setting a maximum bid on a signature Fender Stratocastor; no matter, the user must be able to do that thing easily, without lots of fumbling around. The functionality of your site must be prominent, and carries far more weight than anything else you do. So how functional is your site? In fact, can you clearly and concisely state the core functions of your app? You'd better be able to, and you'd better spend more time on that component of your app than anything single other portion of your design and development.

Form (and design) must support your functions

Of course, it would be a huge mistake to eschew beauty totally. There's a reason that people are spending their money on a PlayStation 3, and the OS X user interface has become wildly popular in recent years. Beauty—specifically, a clean, enjoyable aesthetic—makes a difference to your user. However, any design you come up with should support your functions, and in fact be intrinsically tied to it. Return to the example of Twitter, and take a look at Figure 1. The Twitter Web interface is so painfully simple, and hardly a work of beautiful artsy design.

Figure 1. The Twitter user interface is functional, but still attractive

Everything on the Twitter page supports the core functions; it gives out information about the followers, recent updates, my messages, and basic Twitter information. It's as if the designers made every decision with the core functions of the site in mind.

Return to the idea of movies and television. It would seem at first glance that form, or beauty, is valued far more than function. But that's not the case; why do some shows with questionable production value live on, while others—with hundred-million dollar budgets—flop? The answer is unsurprising if you're willing to get past stereotypes: we like good stories. We like identifiable (which in the technical world translates into "usable") characters with happy endings (which in turn translates into "getting what we want").

In these stories, there may be beautiful costumes and expensive sets, or grainy black-and-white shots that are decades out of date. In both cases, though, the design must support the function. In many TV programs, millions of dollars are spent to ensure that the flashbacks and flash-fowards are believable, and therefore, make the characters they're concerned with believable. Again, the function—the story—trumps everything.

Take a close look at your application. If you pulled out design elements, or certain colors or graphics, would your application be just as effective? Notice that the question isn't, "Would it be as beautiful?" It's simply a question of effectiveness. And it's okay to have an attractive application! But the design elements should highlight key functions. There's a reason that shopping carts on online stores are usually in color or against blocks of color: attention is being drawn to the important functional elements! On the other hand, how realistic your shopping cart image looks doesn't matter a bit.

Back to top

So how do you design for function?

Suppose you really buy into the need of your app to favor function over anything else. How do you actually do that? There are some key principles that you can employ, again and again, to help keep you on task, and keep your designs supportive of your functions.

Define your core functions

As simple as it sounds, the first step in taking your app from a "cool Web app" to an important part of your user's life is to define your core functions. In other words, you need to succinctly state what your application does. You don't get two or three sentences, either; just find one very short, very direct sentence. What is YouTube's core function? To allow users to share and view videos. That's it; nothing more. Amazon.com is even simpler: Provide a comprehensive online marketplace.

Certainly, there's nothing explicit on these sites that states these functional manifestos, but they're evident in every bit of those Web apps. What is your site's core functions? You'll have to dispense with the eye candy, the auxiliary features, the nice-to-haves, and really hone in on what one thing your site should be able to do. But after you've trimmed all the extras, you should be left with a very tight, well-defined functionality statement.

Take that statement, throw it onto a sticky note, tape it to your monitor, do whatever you have to do. (Figure 2 should give you a good idea.)

Figure 2. You have to know, beyond any doubt, your app's core functions

This statement must hang over everything you do. Think back to your competition: TV shows, video games, movies, and so on. What makes these successful? The answer is the just what a well-defined functionality statement provides: focus. Take popular TV shows that have gone on to lose their popularity. You'll often hear these shows (and movies, too) accused of "jumping the shark." That strange term is an allusion to a situational comedy from the 1970s called Happy Days (check it out on Wikipedia if you want more information). But, it basically refers to the point at which a show starts employing gimmicks or silly plot devices that detract from the core purpose of the show. Jumping the shark, then, is using screen effects or design tricks to hide a lack of core functions, if you want to translate things back to the online world.

How do you avoid jumping the shark in your Web app? How do you keep up with the tightly defined (and refined) movies, TV shows, and video games that you've got to compete with in the media marketplace? Define your core function. And then, you can make sure everything on your site and in your app is directed at that core function.

Highlight a path through your functions

After you know what your app is trying to do, you've got to make it clear to your users. But that's not as easy as it might sound; Amazon certainly doesn't slap a big "Buy everything you ever wanted here!" banner across their home page. (Although I imagine some marketing executive has tried that one.) Imagine if the opening segment of a TV series had a black screen with big white letters: "We're back to the stories that made us great in Season One! We promise!" That's more than a bit heavy-handed.

Your users want to experience your core functions, not be told (or sold) about it. You need to guide them through your site in a way that emphasizes these core functions, always keeping it at the forefront of your user's consciousness. Take a close look at Figure 3. What jumps out at you?

Figure 3. Your users should experience your app's core functions

Amazon.com has done a great job of highlighting their core functions. Here's what stands out:

• The two bolded, orange buttons are both for purchasing. One is for upgrading to two-day shipping (which carries purchasing along), and the other is for adding the item to the user's shopping cart.
• The other high-color item, the "Shop All Departments" tab, is certainly in line with "getting everything you need from Amazon.com."
• The product, central to the user's experience, is big, bold, and colorful.
• Everything else is pretty low-key.

The functions of Amazon.com isn't stated anywhere specifically, but it's highlighted through the user interface. The user is guided, quite intentionally, from product selection through purchase.

It's also not surprising that the items that are highlighted change, but the focus never does. For example, Figure 4 is Amazon.com again, this time at the purchasing screen.

Figure 4. The highlighted items in your app should change to match the appropriate function

All the options are reduced to one big orange button: "Place Your Order." At this stage, Amazon doesn't offer you tabs to search the rest of the site, or categories of products (although you can get to all of those areas). That's because Amazon.com understands that at this stage, the user needs to complete their order. The very buttons that were essential on a product page are problematic here. Even a small iconic image of the product would be an issue; it distracts from the purpose of this page, which is to get an order placed.

Find the sticky note you should have written your app's core function. Does your site live up to that message? Are you guiding your users through your site clearly, in accordance with your functions? If not, you're going to lose out to the TV shows, movies, games, and Web applications that make their functions clear and obvious.

Apply the "fuzzy" test to your apps

It's not always easy to balance all the concerns of a Web app. You know that functions are more important than pure design aesthetics, but design clearly is a part of every Web application. (If you don't believe that, try to release any Web app without Cascading Style Sheets (CSS) or inline styles, and see how that goes over!) And here's where your app really is like your competition, in all forms of media: it's easy to get lost in the details.

Whether you're writing a character arc on a weekly TV series, the dialogue for a video game character, or developing a color palette for a Web app, how do you really make sure your function stays front and center? One of the easiest ways is to apply the "fuzzy" test. This is an approach that essentially says, "What parts of your [insert product here] are noticeable at low resolutions; at 10,000 feet?" The term "resolution" here doesn't just mean pixels; it means, when your application or product is seen from far away, what stands out? Is it a cool logo, a flashy CD, a particular character's brilliant red hair? Is it explosions and quirky plot devices? Or is it the core of your production: the core function (refer back to Figure 1 if you've forgotten what this is), or the base story of your movie, or the most engaging bit of gameplay in your XBox 360 title?

Fortunately, this is easy to detect in Web apps; you can literally apply a fuzzy test. Take a quick screen shot of your Web app, and open the screen shot in a graphics application. Blur the entire image several times, until you can't read the text on your page. Taking the Amazon.com shot from Figure 3 and applying a blur to it (it actually took about 5 "Blur More" operations), you'll end up with something like Figure 5.

Figure 5. The "fuzzy" test gets rid of detail in your page

Suddenly, all the details are gone. So what's left to draw the eye? Unsurprisingly, the product image and the bright orange buttons. Even with all the detail done, the right things are still dominant. And don't take your own opinion as truth; after you've blurred your shots, pass them on to a friend. If you can, find someone who knows nothing about your application. What do they notice? What stands out to them? Your goal is to get them to notice the elements that you want users to use, the same elements that relate to your site's core functions.

The nice thing here is that it can do more than just tell you if you're on the right track: the "fuzzy" test gives you insight about your design, about the colors you're using, about the layout of your page; almost everything visual on your site is simplified with this test. Did you spend three hours tweaking the font of a heading? That three hours disappeared with just a blur or two. But if you spent that same three hours adjusting the color of your "Purchase" button so it stands out, then you're rewarded by this 10,000 foot view of your app.

Back to top

So what else can I do with my app?

After you've bought into the idea that you (and your app) have to compete with a lot more than other Web apps, you've got a much tougher task. Suddenly, a compelling storyline is a much bigger issue. It's competing for your users' time, and that means they're competing with your application.

So what else can you do, beyond refining and honing in on your core functions? Well, there's quite a lot, and I'll be looking at those very issues and items over the next several articles. In the meantime, though, there's a lot to think about. Here are some specific things you can do, right now, to improve your app, and maintain some forward thinking as you get ready for the next article in this series.

Watch TV, play video games, surf the Web

Yes, it sounds like odd advice, but it's good advice. How long would a Hollywood exec last if he never bothered to watch the competition's movies? Can you imagine trying to code and write the next great XBox 360 video game if you didn't actually own an XBox 360? It's ludicrous. So get out there, and check out your competition. Find out what TV shows are wildly popular (and preferably have lasted a while; overnight fads aren't what you're going for here). Watch a few episodes using iTunes or your TiVo. Take in the latest blockbuster at the local theater. And of course, surf, surf, surf. Google for the same sort of keywords you'd expect your app to show up under. Visit sites you know are competitors. Explore every corner of the Web, and pay attention to which sites seem to be popular.

While you're doing all of this, take notes, lots of them. What do you like? What do you hate? What seems cool and fun? If you can, get some friends to check out your selections with you, especially the Web sites. Get them to surf around, and interact with the sites, and watch them. What do they do? Are there certain patterns, or buttons, or avenues they follow? What does that tell you? Think about what your users want!

Look for models outside of the Web

Another really helpful tactic to get you out of a Web-centric line of thinking is to think about the behavior you're modeling in your application. For example, do you have any sort of shopping cart or shopping bag? If so, you're modeling inventory. A user builds inventory, and then "uses" that inventory (purchases it, or adds it to a wish list, or so on). How do non-Web mediums represent this? Obviously, you don't really have inventory at a movie theater, unless you count the popcorn and drink you pick up on the way in. But what about video games? Inventory management is a common part of many video games. How do you check your inventory? How do you "pull it up?" Think about what these games do, and how that might translate into your Web app in a new and engaging way.

Note: The next article in this series talks specifically about inventory management, so really spend some time thinking about this one. It will pay off when you get to the next article.

Another interesting model to consider is communication. How do your users communicate with you and your app? Do they click a Contact link and then send an e-mail? Do they pick up the phone? How does that compare the the communication models in other mediums? Again, video games have been dealing with community, social networks, and communication in unique ways for years. What can you learn? What can you apply to your application?

Back to top

Conclusion

Certainly, there's a lot more to take away from really looking at all new media as competition. However, all the Ajax techniques and clever designs (things we'll spend time looking at in future articles, in fact) can't make up for a loss of focus. What's the purpose of your site? How clear is that purpose to your users? What does your site look and feel like when you strip away all your preconceptions and bias? What really stands out?

If you can answer these questions with core functions, then you're already on the track to building competitive, user-friendly, and usable applications. But don't kid yourself; it takes a lot of work. Over the next months, I'll dig deeply into specific techniques to get the most out of the apps. But first, and foremost, work on your core functions. What really matters? What's the most important thing your app does? Spend time figuring that out, and you'll be ready for everything that follows.

Resources

Learn

• Any discussion on Web usability has to start with Jakob Nielsen's Web site, which is full of articles and great resources.
• Closely related to usability is accessibility. A usable site is almost always highly accessible. You can find out more about accessibility at the Web Accessibility Initiative online.
• Read Head First HTML with CSS & XHTML: You'll get a terrific introduction and concept-rich instruction in XHTML and CSS.
• The Web is informing video games, just as video games are informing the Web. Check out how the PlayStation 3 game "Little Big Planet" took Web 2.0 initiatives and built them into the game.
• Read Head First Web Design: You can get into details with usability, color, layout, navigation, and even intellectual property with this learner-friendly book on Web design.

Discuss

• developerWorks blogs: Get involved in the developerWorks community.

Comments

Dig deeper into Web development on developerWorks

• Overview
• New to Web development
• Technical library (tutorials and more)
• Forums
• Open source projects
• Events

• 

  developerWorks Premium

  Exclusive tools to build your next great app. Learn more.

• 

  developerWorks Labs

  Technical resources for innovators and early adopters to experiment with.

• 

  IBM evaluation software

  Evaluate IBM software and solutions, and transform challenges into opportunities.

Back to top