deliciously simple web design & creatively technical writing

• Home
• About
• Gallery
• Archive

Tiny details: the difference between a good and great user-experience

It’s the really tiny details that makes the difference between a good and great user-experience. A bit of brilliant copy that makes the purpose of a particular button self-evident here, a little AJAX trick that saves the user a few seconds by not having to reload the page there, a bit of clever regular expression programming to save the user a few seconds typing or copying and pasting here and there, etc.

Currently, I’m hard at work on a web community and application of my own. It’s my first major solo effort, so I’m working really hard on the tiniest of details, and that’s what I wanted to write a little bit about right here.

I’m unsure of a release date due to being busy with other projects and having an uncertain schedule right now, but I’ll mention details as they become more clear over the next few weeks. The major functionality is largely done, but the endless little details is what is consuming so much time and energy.

I’m not really ready to talk about specifics with this project is yet. Mentioning that the site is written with Ruby on Rails and that the overriding theme of the site has to do with psychology, relationships, and emotions is all I want to say for now. But I wanted to talk a little bit about the design process and the tiny details that go into making a very smooth user experience. And let me just reiterate, design isn’t about decoration, it’s about how something actually works.

Here are a few details I’m currently thinking about and working on. This isn’t by any means an exhaustive list of design issues, but these are a handful of decisions common to almost any larger website or web application.

Registration

Thinking about how best to handle user-registration involves a lot of decision making and examination about the type of application you have. You want people to register and use a site, but in an age of annoying spam and lengthy forms, you don’t want to put barriers in place that prevent a user from deciding to fill out a form and click “Join”.

Pownce has a drop-dead gorgeous registration screen, but is it pretty and also ideal? I think they’re asking for way too much information too soon in the relationship, which might scare off a prospective user who just wants to test the service out. Simple forms are much less intimidating and likely to be filled out.

Commenting on a blog is (usually) very easy because storing any confidential information is unnecessary for commenters. You type your name, email, and optionally a website. But for a system that stores confidential information, having some type of registration is necessary to prevent that information from being exposed.

Theoretically, you could make a registration screen just one field long by only asking for an email address. Then you could mail a randomly generated password to a user and just use an email address as the login. Overall though, trying to make it this simple probably harms the user-experience as it forces the user to have to go back to his email account to get the password. Striking a proper balance between simplicity and complexity is key.

Realistically, arriving at the most usable registration screen (for many web applications) would leave you creating four fields: one for the login name, one for the email address, and one each for a password and confirm password screen. That should be just enough information to allow a user to test drive a few basic features.

For my particular app, I decided to use the in_place_editor_field functionality to allow a user to just click on a particular bit of profile information and edit it very quickly. The Flickr photo site does something similar for editing things like photo titles, and this makes it much quicker to actually perform the task.

Once the user is satisfied that he wants to continue with a particular service, there should be a separate screen to quickly update the user information.

And speaking of user accounts and registration, do you take the time to handle things like OpenID for a decidedly non-technical application? I’d say that it’s important if it can be fit in, but if development time is a priority this particular feature is best spent on the user-interface and other features rather than having something that the vast majority of people haven’t heard of.

But this last thought on registration is probably the most important one. Having a great “About” page with a description, pictures, and ideally a short and clever screencast is helpful to illustrate the usefulness of the site. Exposing as much of the functionality as possible before signup to whet somebody’s appetite is a good thing.

The Blank Slate

When a programmer is writing and testing an application, they’re likely to work with it when it’s already filled with typical dummy data and the screen a user sees when she first signs in and hasn’t yet entered any data isn’t as likely to be polished.

Yet it is the screen she first sees and plays around with that plays a large role in determining whether or not she will find something useful enough to return. If things are too confusing or the benefits aren’t clear, your user could quickly walk and not come back even after registering. So taking out the time to put in place some helpful diagrams, perhaps some help information, a short video, some example data, or something else interesting to explain the benefits is very helpful.

Signals vs. Noise, the fantastic blog of 37signals, has got a great collection of articles on the blank slate and they’re worth checking out.

But this concept of how best to fill in the blank slate leads to other questions. How long should a user see that first example screen? Should the program hide the example data after one or a few items are entered, after a few logins to allow that information plenty of chance to sink in, or should the user have the option to click a hide button that just gets rid of it altogether any time they want?

As I mentioned in my Asoboo review, I really liked the way that Asoboo did their initial help system. When you clicked the button, the item simply faded out of existence.

Simple and sweet.

Form Labels

Depending on the particular situation, you could change the wording on a particular form to make the experience a bit niftier.

For instance, if a user hasn’t entered an item into the app for a couple of weeks, why not modify a bit of view code and have the form say something like, “Hey Joseph, you haven’t entered an item in a while. We thought you were dead!”?

Actually, now that I think about it, too many business software and corporate intranets and the like aren’t fun enough. Definitely try and make some better and more entertaining useful software. I sometimes like to download apps even knowing I’ll delete them just for the chance to hear the little Laser Beam sound going off in AppZapper.

Fun little design touches that make a user smile like that are always to be encouraged, especially on a site with a goal of fun instead of business.

Threadless’s shopping cart smiley is another example of a great little conditionaln touch that makes one smile. If there are no items in the shopping cart, you get a little sad face.

These and other fun little touches should be considered wherever possible.

Relative Dates

Using relative dates is a great way to quickly get across how long ago a particular bit of information was created or modified. Having an application say that a post was entered “about 15 minutes ago” instead of a mass of useless date information like this “2008-01-02 00:46:12″ makes for a better experience.

But what if you’re dealing with a situation where you have a massive influx of information posted simultaneously? Here’s a small screenshot of Digg’s new stories page to illustrate a bit of unnecessary repetition.

The “2 min ago” text is repeated for every item. Yet this contributes towards making a cluttered screen even more cluttered. The more information you have in a given amount of space, the smaller the text has to be and the less white-space there is.

Can Digg’s crack team of programmers create something like this instead and only put in the relative date if there’s been a change from the previous mention of the relative date?

Yes, it’s harder to program this, but anything that removes superfluous data from the screen is a good thing.

And here’s another issue to consider. Is using relative dates a good idea for a date in every single possible range?

For instance, using relative dates to say “about 3 hours ago” or “4 days ago” is perfectly fine. But does it make sense to display something like “853 days ago” or “over 2 years ago” instead of just actually mentioning the actual date? Deciding if relative dates should be used with every possible date or only for a limited time range is also something that should be considered if an application deals with a lot of older data.

Programming complexity

Rails’s MVCness and special folder locations for business logic, controller code, views, helpers, javascript, etc does make it somewhat easier than doing things in PHP and not following a decent design pattern. With a bit of effort, you can keep the amount of business logic in the view down to a bare minimum, ideally just calling methods and having mostly HTML there. But regardless of programming language and your skill in keeping things in their proper place, adding all of these tiny little touches does add a fair bit of extra code and complexity to the system. As a programmer, the more details you have to hold in your short term memory, the harder it is to switch gears and make changes on code.

Also, adding some extra bit of code that adds an additional call to the database or two or throws a few extra objects into memory does make it somewhat harder to keep performance above-board when the site is hit with a heavy load, so this is an additional consideration.

But these are the tiny little details that separate good from great and world-class.

Conclusion

Making all of these tough decisions and programming all of these options into the code does impose a burden on the designer and programmer. But those are the people you want to work hard, not the user. Somebody using your website should never get stuck with unnecessary work trying to figure out how to use your application.

If I would just mindlessly throw tags into my app like any other web2.0 application and copy the typical feature set of many sites, I’d have likely finished by now. But I’m trying to make the best damn stuff I can, not another “me too” site. I’m going to stop right now, because I’m going to go take a break and this article is too long already. I didn’t get the chance to cover every single point I wanted to cover, but hopefully I managed to describe enough issues to illustrate the thought that goes into every single decision.

PS: A shiny congrats goes to anybody who can manage to identify the snazzy sans-serif typeface on the article image.

Posted on March 3rd, 2008 by Chris Papadopoulos.

Subscribe to the RSS feed, Trackback, or contact me privately.

Comments

Agree or Disagree?

Your Name (required)


Your E-mail (required)


Your Website (optional)


Your Comment

Notify me of followup comments via e-mail