Making a Web App: Part 13 - Designing for Speed
by Scott on October 03, 2007
Common application design goals are:
- Stickiness: To encourage people to stay as long as possible.
- Personality: To set a mood or personality such as friendly, exciting, young, bold, or reliable.
- Buzz: To get people to share the site with others.
For PlaybookIQ, most of these design goals are important, yet I do not have any of them as the primary design goal. For Playbook, I have one design goal:
- Speed. How fast can people enter, find, read, and update information. How fast can they get in, get the information they need, and get on with their real work.
The faster, the better. The application’s personality, stickiness, buzz, and revenue drivers will come from the application’s website. The application itself is designed for speed.
Here’s where the other design goals fall.
Stickiness: great for the product site, ok for the product. In a business app, people want to be “in” the app as little as possible. They have a job to do, a business to run. It is not their job to be using the application. In most cases, their business is not the app.
Personality: great for the product site, also important for the product. People want to have an enjoyable experience in any application, business or consumer. But for this application, I do not make design decisions based on trying to create a personality for it: other than the trait of “fast”.
Buzz: great for the product site, ok for the product. If the product does what businesses need it to do, and does it well, it will generate buzz. Again, I don’t let yearning for buzz get in the way of what people really need in the day-to-day use of the app. I don’t add a slick feature or integrate with a product just to get press. That buzz from that feature will eventually wear off, but we’ll be left to support it forever.
What Makes for Speed?
So, speed is the primary design goal, but what does that mean for the app? Here are a few thoughts that came to mind when building Playbook.
Show more fields by default:
It is a popular design decision to hide fields until they are needed. This makes for a clean look and less clutter. While less clutter initially makes for a more efficient form, the extra clicks necessary to “show more fields”, for example, slow down the use of the product.
Focus
Always through focus to the first field on the form to that someone entering new information can simply open the form and type.
Color and Contrast:
Generally, the higher the contrast, the quicker the read.
Position:
In a previous post, I’ve already talked about little things like persistent search box and the position of elements. For example, people need sign-posts and context to efficiently navigate and understand information.
English language readers scan from top left to bottom right. So, the most commonly sought information should be at the top left. Less commonly used information, or sections of the screen that do not change often, should be to the right and bottom.
For example, when someone opens up an Opportunity sheet in Playbook, I do not want them to have to glance past the “New”, “Edit”, “Add Person”, “Add Comment”, “Add Task” and other buttons to get to the information they seek. The goal is to imagine someone scanning from top-left to bottom-right and get everything out of the way. Because these buttons are there in the same place every time someone opens that screen, they will easily find them if needed. They do not need to be reminded of them each and every time they want to look up notes on an Opportunity. So, supporting information and navigation items having to do with this opportunity, go to the right of the opportunity detail sheet.
There is one exception to this guideline – context and sign-posts.
Context and Sign-Posts:
The importance of context and sign-posts trump the importance of placing commonly sought information to the top left. For example, persistent navigation tabs should be above the detailed information being presented. The app’s name or the current screen is commonly found at the top. This is not typically information someone is seeking, yet to provide context (e.g. you are in ABC app, at the “Add a widget” screen), it is important to show it.
Because people think of things that are under and to the right of something as being “within” or a “subset” of things above and to the left of them, context indicators and sign-posts should be at the top and left.
For each screen, I like to think of someone scanning it from top left to bottom right.
Switching Gears
After spending too much time playing around with different fonts, color combinations, and field and button placement to get a good “look”, I decided to switch gears and read empirical research on what layouts provide the fastest user experience.
While there is no definitive evidence for color and font selection for web applications, there are many studies. I’ve taken the results of those into account in a new design for PlaybookIQ.
For this reason, the resulting product screens are different than what I have been previewing here. Just how different will be revealed when the product is ready for beta testers.
[3] comments
