On Web App Design
Here are some concepts that have surfaced while doing some recent web app consulting and design. This information is all out there on the web for the taking, but so many apps get these items wrong that I’m motivated to share them here as a checklist for myself and to hopefully help others make what’s special and exciting about their apps really shine. To clarify up front, it’s obvious that if your app isn’t going to be of the me-too variety, it will need to be different from existing web apps in some significant way. However, for the majority of the interactions in your app, choosing to stray away from some best practices can simply derail the user experience. Also, most of the following suggestions are related to usability and less about graphic design. I’ve never thought of Google’s apps, for example, as excessively pretty, but they are often usable.
A Feature By Any Other Name
Ok, you’ve got a sweet domain name and corresponding product name, and you want to run with a metaphor for your features (maybe you have a ‘pirate ship’, users are ‘pirates’, friends are ‘maties’…) That’s a cool idea, but if you’re going have common features, like following other users in a social network, it’s better to stick with the terminology that everyone already understands and not force your users to learn something new. The following are some terms that I think web apps should stick with.
- ‘follow’ people or groups of people
- ‘like’ objects (items or things, such as posts on Facebook, a book review, a movie, etc. - ‘favorite’ or star icons can be used here as well…)
- ‘groups’ are collections of people
- ‘lists’ are collections of objects (and sometimes people)
- ‘tags’ are keywords or descriptions usually attached to objects
It should be noted that choosing ‘groups’ or ‘lists’ can be a bit tricky. ‘Lists’ tends to be used for user-created collections of things. However, those things can be objects (products in an Amazon Wishlist) or even other users (like Twitter lists). ‘Groups’ tend to be collections of people centered around some kind of shared interest. Facebook, LinkedIn, and FriendFeed all allow users to create groups for topics (similar to organizations in real life). ‘Lists’ tend to be more geared towards allowing an individual to curate or organize, while ‘groups’ are more geared towards serving more than one person and where collaboration and communication are implicit. ‘Lists’ allow people to filter the often overwhelming river of information within an app, and ‘groups’ help people work together to create as well as filter content.
Regarding tagging, tags are a sort of brilliant catch-all for letting users organize information. In my listing above, the ‘usually’ hints at the fact that tags can be used for anything. You can tag people, groups, lists, and objects. Now, do you want to allow that sort of power tagging? Probably not. First of all, tagging is hard enough for a lot of users to grok, but also, it’s not likely users will want to go that hog-wild tagging everything in your app! It’s much wiser to not include a feature like this and let user demand for it determine for you if it’s even needed at all. I would suggest not even including tagging as a feature at first unless it’s core to the functionality of your app.
Attention To Detail
Let’s be honest, if you’re lucky enough to have a user at all, that user will have the entirety of the interwebz to compete for their attention. Therefore, you should make your app well-suited to drive-by usage. FriendFeed’s UX was validated by its acquisition by Facebook, which had already stolen some great features from them (see more below about stealing.) Being able to ‘like’ and comment right inline with an item in a news feed (or ‘activity stream’) is incredibly convenient. The old school web 2.0 way of handling this would be to require the user to click through to a details page where the item is displayed with relevant metadata and allow commenting/liking/etc from there. Why make users leave the stream to engage when they are probably just scanning items that look interesting and moving on quickly? Ask yourself if you truly even need a details page, and if you do, consider allowing any features on that item to be accessible within the stream or list view where multiple items appear. FriendFeed actually does have a details page (it’s buried in the ‘share’ link menu), but I think that was really only there to attach a permalink to the item for reference outside of the app. Twitter obscures their tweet detail page as well (you have to click on the timestamp to open it). Facebook doesn’t even bother!
For Every Action…
Any amount of user testing will illuminate the tendency for humans to become impatient when an action they take seemingly has no effect. For example, if I click a submit button on a form and there’s no indication that something is loading and I don’t know to look at the browser’s loading bar, I might think my click didn’t work. That’s when I become amazingly good at breaking your web app! Waiting for third-party API responses or just simply the load time for a page is still a factor we need to account for, so be nice to users by letting them know their input was received and something is happening.
One way to make this clear to users is to have reverse functionality replace the initial call-to-action. If you have a ‘like’ button or link, you can simply change it to ‘un-like’ and that lets people know both that their action has been completed successfully as well as making it obvious how to undo or change the results of their action. Do the same thing with follow/unfollow. Put ‘edit’ links inline with the content they effect; people click where their eyes are focused. If your app flow allows it, load search or filtered results via ajax calls to avoid a whole new page load and display a loading icon or text right next to the submit button, since that’s where the user’s eyes are when they clicked (as opposed to text at the top of a form…) You can even use jQuery or similar to change button text to indicate something is happening. For example, ‘search’ can be changed to ‘searching…’ Yes, following this suggestion creates some hoops for us web developers to jump through, but sprinkle in a little ajax magic and your users and customer support staff will be much happier. If you do a good job of communicating activity that’s occurring, you can also disable buttons/links by graying them out and making the cursor be the default arrow on mouseover to indicate the item is no longer clickable. If you do this kind of thing, just make sure to include timeout logic in the back-end to avoid infinite loading or allow users to cancel the action or your app might appear frozen.
Keep It Moving
Never allow users to reach a dead-end in your app. If they search for an object that doesn’t exist, let them know that it doesn’t exist and give them one or more calls-to-action to find something related or notable. “We couldn’t find ‘pink leather pants’, but check out these popular pink items by other users…” If your web app is new or doesn’t have much content on it, take advantage of the lack of stuff to prompt users to add stuff. “You don’t have any bookmarks yet. Add some bookmarks by…See some popular bookmarks…” This creates motivation in your user instead of making the app feel broken or limited. Never make a link direct users somewhere different because they haven’t added content or completed some sort of sign up or profile action. Show them that there’s a gap in completeness (LinkedIn’s percent complete and corresponding call-to-action is a classic example) where they have an opportunity to add info that will enhance their experience (gain attention, better share with friends, help others by being a maven, express themselves…you get the idea!)
Stealing Is Smart
As Picasso once said, “good artists borrow, great artists steal!” If your app has an activity stream like Facebook, FriendFeed, or Twitter, make it look like something like those UIs. Chances are the developers and business decision makers behind these products have more resources than you, so you can get tons of free user experience consulting by just copying these apps. Does your app have a sidebar with items like Twitter (an avatar and username on a user profile, groups of users following the user, users they follow…)? Well, make your life and your users’ lives easier by just lifting the UI straight off Twitter! You probably have a different brand/look/feel than Twitter, so you should skin the content accordingly, but steal enough to make it easy for users to understand what’s going on at a glance.
Spend a couple of honest moments asking yourself which features are truly special in your app. Put those features front and center and make all the other stuff easy to use by keeping it familiar to users of more popular sites. You will be hard pressed to out-user test someone like Google, so don’t bother trying and steal their good ideas!
That’s all for now. Have any tips/tricks/guidelines you’d like to add? Agree or disagree on any of these points? Comment! Respond! Take action and shout it out!
