Monthly Archives: April 2009

Adding Grid Focus to Sketching

Adding Grid Focus to a group sketching activity is, in my opinion, a great example of how a small additional effort early in the development of a design idea can have a large beneficial impact over time.

What is Grid-Focused Sketching?

Grid Focus, in the context of sketching, is simply to ensure that the page grid and layout is actively discussed as part of a group ideation activity.  Too often, while the sketches team members produce may imply a certain layout, the choice of layout is rarely explicitly discussed, and is instead something left to the visual designer to figure out on their own at a later point.

This is a big mistake in my opinion. And the mistake is tied to an archaic print-world notion that the page grid is the domain of the visual designer.  The reality, of course, is that the choice of page layout can have a significant impact on user experience and that, in contrast to print, layout in the digital domain has a dynamic potential that many visual designers may not be considering.

For this reason, engaging the entire team, particularly UX and Tech leads, in defining the grid at the sketching stage can make for a better design solution, mitigate possible aggravation and headaches down the road, as well as allow for an overall more efficient design process.

So how does Grid Focus work?
Obviously, that will depend on the idiosyncrasies of your team’s process, but here is one possible example:

Imagine your team is in front of the whiteboard, various team members drawing and commenting on one anothers ideas. Once a design idea has begun to take shape, you shift your discussion to page layout.  These are some possible questions you might discuss as part of a grid focus.

Is there a legacy layout?
If you are redesigning an existing application, there is commonly an urge to discard the old layout and replace it with something new.  Switching to a new layout, particularly for legacy users, can be quite risky, since they’ve learned to expect that certain types of features and information are located in certain parts of the page.  That is not to say that one shouldn’t explore new layouts, rather that the team as a whole should be aware of the potential risks, so that the visual designer doesn’t go off and create a completely new layout without considering legacy issues.

Should we go with a standard or custom layout?
Though it may not be apparent to non-designers, most web pages are designed using one of a small number of standard layouts, generally either a two-column or three-column layout.

Choosing one of these layouts is likely to both be more cost-effective in terms of implementation, i.e. a front-end developer will be able to much more quickly create a three-column layout, compared to something more customized, and also less risky in terms of user experience, since information is organized in a way that users are more likely to recognize.

Therefore, a standard/custom layout cost-benefit discussion should happen early on, rather than allow the visual designer to spend time creating a fancy custom layout, only to then learn that it will be a major headache to build. Of course, if you are designing a highly brand-intensive site (e.g. a fashion site), there might be a strong business case to be made for investing time in a custom layout, but it should still be explicitly discussed early on.

What will be the roles of various page regions?
As we are sketching out ideas, we often draw boxes representing various parts of the screen.  What we don’t do often enough, in my experience, is to discuss the larger role of a given page region within the overall application context.  For example, in a 3-column layout, do we want to use the 3rd column for contextual help information related to the 2nd column, which will contain the primary page content? Discussing page regions in terms of these roles can facilitate creating a more consistent experience across the entire application, with the same type of information consistently appearing in the same region.

How does this layout work relative to that of the referring page?
Something easily forgotten when working on the design of an individual template is that the page is part of a larger flow.  In other words, the user will in most cases be arriving at this page from another page in the application, for which reason it is critical to be looking at the relationship between this page’s grid relative to that of the referring page. When moving between application pages, one ideally only wants the page region relevant to the current flow to change, since it is the part that shifts on the page that will draw the user’s eye. In other words, let’s say we are working on designing a product detail template.  In doing so, we also want to be looking at it in terms of the transition to that page from the page likely to precede it in a user flow, such as a products listing page.  If those two pages are designed using significantly different grids, and the same information appears in different locations on the two templates, that is certain to disorient users.  Just as filmmakers talk about everything being ‘in the cut,’ so too is how pages are juxtaposed a critical factor in user experience.

Do we want the layout to respond to user behavior, window size, medium, or user agent?
In contrast to print, in which there is one and only one grid per page, a single page in the digital domain can be highly dynamic, i.e. the grid can change depending on any number of factors, such as  what type of user agent (e.g. Firefox or Internet Explorer) is being used, the size of the browser window, the output medium (screen, print, projection), or some user behavior.  One major reason, I think, why so many pages are designed using only one static unchanging layout regardless of these factors is because it has been created with a print-world mentality.  But by opening up the grid discussion during sketching, we great a much better opportunity for taking advantage of the range of dynamic grid choices.

For example, let’s say we have a 3 column grid for the default web view, but maybe it makes more sense to go with a 1-column grid for print, in which we maybe remove the first column altogether (let’s say the first column only contains navigation) and float the 3rd column to be down below the 2nd column, which would make sense from a linear reading perspective, particularly if the 3rd column contains additional reference or help information related to but secondary to the main content in the 2nd column.

This type of broader thinking relating to the page grid is, in my experience, much easier to accomplish as a team, allowing us to consider and design for the range of ways in which users might experience our product.

Three Amazon Design Ideas

Inspired, in part, by Jared Spool’s recent article regarding  the impact of design changes at Amazon.com and the related talk he gave at the IA Summit, I thought I’d post a few Amazon redesign ideas that have been percolating in my head of late. Of course, these ideas are presented without access to Amazon’s vast research data or internal business knowledge. Who knows, with that knowledge in hand, I may have suggested very different ideas.

A Pixel Saved is a Penny Million Dollars Earned

There are few sites on the web where even an atomic-level change in the user interface can potentially have greater impact on overall product sales than at Amazon.com. For this reason, every character, every pixel needs to be scrutinized and justified in terms of supporting the overall goals of the business. In line with that, these are some ideas for eliminating possibly detrimental pixels in the all-important Add-to-cart area.

Here is a Before/After of the Shopping Cart area on an Amazon detail page:

Current version

Add to Shopping Cart - before

My version

Add to Shopping Cart - after

There are three key changes I made here, which allowed for eliminating quite a few pixels:

  • Removed the quantity option: The ability to select a quantity prior to adding an item to one’s cart seems to not only be an edge case, but also something which, if the option were removed, would be unlikely to cause users to not add the item to their cart. After all, once having added it, they can then update the quantity option to their heart’s content. Removing it, in other words, would mean less page noise at virtually no cost to usability.
  • Removed an unnecessary technology reference: Below the Add to Shopping Cart button, anonymous users see a link and some copy encouraging them to sign in to be able to make use of 1-Click Ordering.  The problem here is two-fold. First, by linking on the word  “Sign in” this is what is implied as the main goal of the message and also what will draw the eye.  Signing in is of course not the main message here.  Second, even including the detail that accessing the 1-Click-Ordering feature will require signing in really only becomes a distraction, since it really isn’t relevant until a customer actually decides that they want to activate the feature.  The primary message is to encourage users to turn on 1-Click-Ordering, and that seems to therefore be most effectively communicated by replacing the whole ball of wax with a single call to action.
  • Combined multiple modules into one and added some hierarchy: Because Amazon provides so many great purchasing options, this tends to lead to a whole gaggle of buttons collecting in this area, some of which are inside a module and some of which are not, making for a slightly harried viewing experience.  Here, I cleaned up the whole thing by placing everything in one module, and then used the dotted horizontal rule as a much more low-key division between groupings.  I also added a bit more hierarchy, such as making the text for the somewhat secondary “Share with Friends” feature smaller.

Much of what is manifested in these changes is the critical value of succinct writing skills. Good user interface design is very much like good writing, i.e. the ability to say what you have to say with the fewest possible words and then saying no more. (As opposed to this completely extraneous sentence.)

Make marketing action-driven

Here is an example of a marketing blurb for the new Kindle 2.

Kindle Promo, Current Version

A key issue with this message is that it requires the user to read through a bunch of copy to understand what really is a simple message (see below.)  Already there, you’re going to lose quite a few users, who, after encountering that amount of copy (a lot in this particular context), will be off scanning some other part of the page.

Then, and this is even worse, for those users who take the time to read the message and in fact would now like to take the action that the message is promoting, it is in fact not at all clear how they should do that.  Should I click on the link with the name of book? But that’s the page I’m already on.  Hmmm…

Finally, the message suffers from providing information at a level of detail beyond what the user really needs to know. For all intents and purposes, “in under a minute” is the same as now, which of course is a far more compact and powerful message.  That’s what customers care about. That’s the essential selling point.

Therefore, my recommendation is to replace this text-heavy marketing message with one that strips it down to its absolute essence and doubles as the action that the message is selling.

Kindle Promo - Redesign

Here, we are not only communicating that the Kindle allows for reading a book immediately (which is a major selling point that I actually was not aware of until I started reading the Kindle marketing materials more closely), but we are also presenting a clear path for initiating that process.

Less page, more opportunity

Currently, the Amazon page width is set to 100% max-width, meaning that the maximum width of the page will be whatever the width is of the browser window.  Now, for users with smaller monitors, this issue will go unnoticed, but for the growing number of us with wide screen monitors, an Amazon page might look something like this:
Amazon wide page view

With a page this wide, the overall page design quickly starts to break down: the long lines of text become more difficult to read, the search input form becomes so ridiculously long it ceases to look like a text field, and the Add to Cart area loses its association with the content it is referencing and looks more like a third column.

Allowing the page to continue expanding to this width is, in my opinion, not only a degradation of the overall user experience, but also an opportunity lost. In other words, constraining the page width to one that is optimal to the content it contains creates a whole new area available for things like marketing. This is something that others, like the good folks at Pandora, already have figured out.  So, my recommendation here would be to constrain the page width to one optimal for reading, which, for the current design seems to be a 1024 pixel display, and then use the new-found real estate for marketing purposes.  Something like this:

wide-screen-view-constrained

Better legibility, usablity, and new-found marketing opportunities all-in-one.

To be clear, I think Amazon is one of the best designed e-commerce sites on the web, and I’m sure that an incredible amount of thought and effort went into the designs I am critiquing.  But maybe it is that very fact, the knowledge that these pages were designed by some of the most skilled people in the industry, which makes it all the more enticing to find ways to improve upon their ideas.