Photos by Chris Nodder.

Not surprisingly, there were a wide range of opinions.  More surprisingly, for such a large group, we were able to keep our discussion focused and productive.  These are some of the big take-aways that stood out in my mind.

The Us/Them Challenge

We intentionally had attendees with a mix of backgrounds, including UX designers, developers, testers, and managers.  A consistent theme throughout the event was that of the Us/Them challenge, of how the separation of work among team members is a fundamentally negative force working against the project’s chances of success, and goes to the core of why traditional waterfall methods so commonly fail.  That separation, be it via role-based silos, throwing work over fences created by phases of work, or the underlying mentality that What I Do Is Different From What You Do, is the source of the Us/Them camps within teams and the havoc they create.  Agile, in contrast, seeks to minimize the Them and maximize the Us, not just through focusing on distributed knowledge, but also on distributed understanding and empathy for other team members.

We tussled over the issue of how much work UX designers should be doing on their own, how much work they should be doing up front before involving developers, and ended up rallying around the cause of the barely sufficient Iteration Zero, of doing the absolute minimum separately from other team members throughout the project.  And when Us/Them thinking would creep into our discussion, such as when a UX designer started talking about the importance of alone time, someone else would call out “Us/Them, Us/Them!” as a kind of mantra of the event.

What is the relationship between UX and the Agile team?

We had a lot of interesting discussion re. where UX fits into, or what its relationship is, to the Agile team.  The idea that UX should be more a competency and less a role resonated strongly. Alan likened the software team to a sports team on a field, in which everyone has set roles but their actual work can be fluid across the field/project. We also discussed the role of the UX Developer, a prototyping competency dedicated specifically to simulating User Experience, as a powerful pattern in Agile UX – at least two of those attending were from organizations that had independently adopted this practice.

Toward a Post-Agile Paradigm

But perhaps the most interesting take-away from this event was that there was a strong feeling among us that we are moving toward (or have already entered) a Post-Agile Paradigm, meaning that what we really are talking about here is not the Agile your grandparents knew and loved, er, I mean the Agile which the original signatories (of which one of them, Ward, was attending) articulated in 2001.  Remember, Agile in its original form is largely silent about UX.  Our conversation was about a paradigm in which the voice of UX plays an equal role in the project chorus.

Here are a some nugget quotes from the event:

Proccesses that are able to embrace the unexpected will look sloppy to the outsider. -Ward Cunningham

The only products that are really done are the ones that die. - Jeff Patton

If you work really hard to please your customer you will most likely fail. If you work really hard to please your user you will most likely succeed. -Alan Cooper

Iteration Zero is about paying down strategic debt. -Desiree Sy

Product ownership is a team effort. -[Don't recall who said that]

At the end of the event, Lane was leading us through a root-cause analysis, to help us drill down into specific causes and corresponding actions we might take.  We actually were not able to quite finish this exercise before we ran out of time, which sort of left us with a kind of cliff-hanger motivating us to organize a follow-on event, which I very much hope we can do in the near future.

Also, other attendees have posted links to their blog posts about the event at the Agile Experience Design social network.

Thanks to the following companies who made this event possible!

Atomic Object, Cooper, HP, Pivotal Labs, and TechSmith.

In the Interfacing course, an art student would pair up with a student from the School of Electrical Engineering to collaborate in building a series of electronic interactive art pieces.  Since I had registered for the course via the School of Art, I was considered the “artist” and was paired up with an engineering student.  Together, we developed our project idea, an analog radio that would tune itself based on proximity sensors, allowing people passing by to discover that their movement was affecting the radio frequency.  Then, we created a circuit board from scratch, soldered on all the necessary electronics, and programmed a 10K chip with the logic needed to have input from the proximity sensor drive a motor attached to the tuning wheel of the radio.

While we only had mixed success with our nifty little human proximity tuner, the most important lesson was that of working across and truly integrating two disciplines, in this case art and engineering, and discovering that what the other does is not as mysterious and weird as one might think.  I didn’t know it at the time, but this was my first foray into Pairing, a concept currently receiving widespread and well-deserved attention thanks to the Agile movement. Pairing is most well-know in the form of Pair Programming, in which two developers share one keyboard, one “driving” (i.e. typing), the other “navigating” (i.e. telling the other programmer what to type.)  To an outsider, this may seem a strange ritual indeed, but it is in fact a powerful way of generating a highly focused whole-brain work session, in which one person is continually debugging the work of the other. (I.e. as the driver types, they are also thinking about and evaluating everything the navigator tells them to type, able to continually make course-corrections.)

In our case, we were pairing across disciplines, which can be just as powerful.  It becomes an act of debugging or evaluating the work of the other across dimensions.  While the engineer may be deep in their C programming mode, I am thinking about how the resulting code will impact the experience of people walking in front of the tuner.  While the engineer is gaining a deeper awareness of the impact of their coding choices on the people interacting with the machine, I as the “artist” am gaining a deeper appreciation for the complexities of software development (for example, when programming a chip, you can’t call a library function such as “abs()” to get an absolute value, you have to actually write an algorithm for that from scratch.)

Unfortunately, this type of cross-disciplinary pairing is, as far as I know, incredibly rare in academia.  Instead, artists or designers are often housed separately and away from engineers and computer scientists, rarely if ever having any contact with one another. The same seems to hold true for those in the interaction and graphic design fields. Until my first day on my first job out of school as an Information Architect at a small web agency, I had never worked with a graphic designer. I have to wonder how many of those students currently studying interaction design are spending time working side-by-side with software developers.  Based on my informal survey, the amount of time they spend together in academia is approximately zilch.

It is no wonder, then, that so many people in the interaction design community I have spoken with seem to think of developers as the Other, as people who simply are different from Us, who simply do not understand the subtleties and nuances of designing a user experience, who do not think the same way that We do. It is no wonder that so many people in the interaction design community suffer from what I call The Genius Problem, in which they see themselves as the creators of ideas, while developers are mere builders, construction workers who transform these ideas into reality.  It is no wonder that so many people in the interaction design community greet the idea of Agile software development with a high degree of suspicion.  It is no wonder because that is a mindset that academic institutions (unwittingly) have indoctrinated them into during the formative years of their practice.

As long as academic institutions in general, and interaction design programs specifically, do not begin to truly integrate their students with those in the computer science departments, this problem will persist.  Agile should not be something that is only taught in computer science departments, and only discovered by interaction designers on their first day at work.  For Agile to be effective, these students need come into these roles with an understanding of what they do as not being something separate from what software developers do.  And for that to happen, computer programming students should be spending time with graphic design students, graphic design students should be spending time with interaction design students, interaction design students should be spending time with computer science students, and so forth. Until that happens, the integration of Agile with other disciplines will continue to be a perpetual struggle.

The second is by Cennydd Bowles and is a great primer on Agile UX.

Enjoy!

If you want to kick-start your Agile practice or just enrich your current practice, you should definitely consider taking one of his upcoming workshops.  Here are a few reasons why:

The Workshop Itself is Agile

I’ve been to all too many workshops where someone basically drones their way through a big Powerpoint deck for several hours, all while attendees do their best to not fall asleep.  In contrast, Jeff’s workshops are not only highly participatory, but also apply numerous Agile methods, such as discussion timeboxing, using the Pomodoro technique with little Pomodoro timers used both by Jeff while discussing concepts (in 25-minute Pomodoros) and by groups when completing activities (e.g. we’d get 5-minutes to do some Storystorming and then be asked to start our little timers)…

…as well as lots of lots of low-cost/high-visibility artifacts that we, the attendees, participate in creating, such as these Agile Personas…

There are few better ways of learning and understanding new concepts than actually engaging in them, and I think this is particularly true for Traditionalists journeying to an Agile practice, since many Agile methods can appear completely alien to a traditionalist, so the best way understand their power is to actually experience them.

Perhaps the most interesting or unexpected application of Agile thinking is how attendees are introduced. Instead of the vanilla round robin of introductions, which at best tends to be a ho-hum when-will-the-actual-workshop-start activity, Jeff instead had us briefly interview the person sitting next to us, and then share with the rest of the group what we learned about the attendee we interviewed.

This was a perfect segway into a discussion about how Conversation lies at the core of an Agile practice.  Instead of passively listening to others talk about themselves, we have been engaged, and have now already connected with at least one other person in the group, the first step in the mini-teams that emerge as the workshop progresses.  Maybe more importantly, we are required to listen, to be attentive to the person we are speaking with, since we know that we will soon need to deliver a working version, as it were, of what we’ve heard, to the team.  To paraphrase Ward Cunningham, one of the fundamental goals of Agile was to get developers to talk to (and by implication also listen to) their customers.  This interview activity, I think is a great way of manifesting that thinking.

Jeff can probably explain Stories better than anyone else on the planet

Yes, Mike Cohn may have written the book on stories, but at least for me, even after having read that book many years back, I credit Jeff with really helping me see the light in understanding what is an essential aspect of Agile. And by that I mean not only the physical manifestation of stories, such as 3×5 cards, but the thinking that underlies their use.

For someone coming from a traditional requirements management practice, with rigorous requirements and change management systems, the idea of jotting down what you need the application to be able to do on small pieces of paper will likely seem awfully  strange.  Jeff does a fantastic job of conveying how stories in fact are incredibly powerful little pieces in that cooperative game we call software development. In the workshop, he used several techniques, from silent and conversational story-storming (like brainstorming, but you write down every feature you can think of onto a story card), to how those stories are transformed into a model of the application with story mapping, and how we can use the story maps to create holistic groups of stories that span a user flow, rather than being divided into entities, as is more common in traditional unit-based software development.

These are some pictures of workshop participants in the midst of a story mapping activity, which organically integrates stories into the design process, and serves as a powerful technique for inter-relating, prioritizing, and dividing stories into sprints.

Maybe the strongest testament to the power of this workshop was a shift in mindset by one of the members in my group.  She said she came to the workshop highly skeptical about Agile, but left feeling that she actually understood it and was looking forward to start applying Agile techniques with her team.

Bonus Reason: If you’re lucky, you’ll get to go out for drinks with Alistair Cockburn afterwards

Since the workshop is held in Salt Lake City, which sort of is ground zero for Agile, you might also get a chance to hang out with some of the originators of a lot of the ideas that Jeff presents.  After the workshop, some of us went out for drinks, and we met up with Alistair Cockburn, who also lives in the area, and aside from being a leading Agile thinker, Alistair is also a beer connoisseur, and provided extensive advice on which beer to select from the The Bayou’s ginormous beer selection.

Hey, every great workshop deserves a great beer!

This lack of attention to the impact of the non-visible aspects of a system on the user experience is, in my opinion, a major reason for a lot of bad user experiences.  If you think about it, if your page is slow to load, if you try typing into a text field but nothing happens, if some seemingly simple action in the UI in fact initiates connections to a bunch of data sources and causes whole interface to become sluggish, who cares how perfect your UI design is?

I think a lot of UX designers shrug their shoulders at issues like this.  Hey, that’s the developer’s problem not mine, right?  Yup, definitely the developer’s problem, just like the proverbial leak on his side of the boat is his problem and not yours.

The issue here is not one of who is responsible, rather one of an awareness that it may critically impact the user experience, and therefore the User Experience design process should be one that allows for surfacing the issue and addressing it.  Current conventional methods of UX design, i.e. focusing solely on the user interface first, then waiting to deal with pesky issues such as load time later is only likely to ensure that those issues get relegated to the revolving “Phase 2″ version of the application.  A better way to address this is to rethink the relationship between UX design and development, and a great example of that is to evolve the GUI in tandem with the software build.

An Agile UX Method: Functionality First, GUI Second

The idea of designing the user interface in tandem with the build is a good example of applying Agile thinking to UX.  Here, instead of first creating some fully formed interface concept before starting to actually implement it, we take a step back and look at what underlying functionality needs to be developed.  In cases where it makes sense, such as a piece of  functionality that may be simple at the user interface level  but where there may be some heavy lifting on the back end, rather than spend a lot of time at the outset trying to come up with the perfectly user-friendly UI, we instead abstract out what inputs the user will provide and what outputs the system must return and then create a minimal user interface, of which the most standard is the command line interface.

Example of a minimal user interface, showing only inputs and outputs

Here is an example of an auto parts search, in which we know that actually connecting to the various parts warehouses and then executing the search is going to be highly complex.  Therefore, before spending a bunch of time designing a GUI, which will need to make assumptions, for example, about the amount of time that will be required to complete a search, we instead start by building a first iteration of the search functionality and use a skeleton user interface.  With the knowledge of the actual average time of completing a search, as well as issues related to connecting to the warehouses, we are in a much better position to build a graphical user interface around this, in which we can clearly set user expectations, as well as determine much more effectively what forms of dynamic features in the UI we can support, such as how much flexibility we can allow for in terms of user inputs. (I.e. maybe we discover that Name needs to be a separate field from ID or whatever.)

This can be an incredibly powerful way of working, since it actively and organically involves developers into the design process, allowing you to collaborate much more closely in evolving the user interface.

Most UX Practitioners Never Actually Create Anything Real

By Real, I mean actual working software that you can do something with, that is neither a simulation or a prototype, but is in fact the gosh-darn real deal. When was the last time you actually wrote real working code? If your answer is “not long ago” then I applaud you, but I also lament the fact that you probably are in the minority within the UX discipline.

So why is this a big deal? Well, it is for several reasons…

If you’re not building stuff, you’re removed from reality

What if you were writing a book about gardening but had never actually dug your fingers into the dirt, never actually planted vegetables, never watered and nursed them and kept weeds from suffocating them, never felt the joy of seeing them take root and grow and bear fruit.  How could one possibly write a book about gardening without these real, tactile experiences?  It would obviously be impossible, right?  But designing software is in many ways no different from gardening, and to understand software, to know how to design it and get the most out of it, to have a blooming, thriving crop, as it were, well you’re going to have get your hands dirty.

So am I saying that all UX designers need to become software developers?  Absolutely not.  But what I am saying is that unless you regularly dig around in some code, you’re going to lose touch with the reality you’re designing for.  Additionally, you’re going to lose your empathy for the people you’re designing for.

If you’re not building stuff, you’ll have less empathy for those who do

No, by people I’m not talking about end users.  Yes, empathy for the end user is important, but that’s a completely different issue.  I’m talking about your actual target audience, which is not the end users. (They are the target audience of the product itself.)  The actual target audience of the work that you produce is the developers (and, depending on your team or project, other roles, such as visual designers.)

And believe me, if you’ve personally had to write production grade code, I can guarantee that it will impact how you approach your design solutions.  You will, for example, think twice about throwing in some gratuitously cool feature.  For the person with no coding experience, that little dynamic widget thing they dropped in their wireframe took them maybe all of 30 seconds to add.  In other words, there is a complete disconnect between their work and the reality associated with this feature. And that reality is that 30 seconds of UX work can equal a full day’s work for a developer.  Does that mean we should not innovate and continue pushing the envelope?  Of course not.  It simply means that one should be more pragmatic, and defer to the standard solution in most cases, and then innovate in places where you really can make a strong case for that it is worth the effort.

By simply having more of a general appreciation for what is involved in coding something, you can save yourself and your team so much of the time and headache that tends to go into back and forth of a developer having to explain to the UX Lead that, um, yeah, that thing you got in there is pretty darn complex.  Instead, you might be able to empower your design skills by thinking a bit more like a developer.

If you’re not building stuff, you’ll never understand how developers think

I remember many years ago toiling away at a deck of wireframes for a content management system, only to later discover that my detailed design ideas were largely being ignored by the developers.  Why?  Because after reviewing my wireframes, they had then taken a broader perspective on the problem, and decided to use an off-the-shelf CMS framework.  As it happened, that CMS framework came with a default user interface out of the box. In other words, my approach of focusing on the UI rather than on focusing on the design of the overall system led me to wasting a lot of time.

The developer perspective turned the whole UI design process on its head.  Instead of starting by designing a UI, it here was more effective to leverage an existing UI standard and then shift from a design exercise to a customization exercise of that UI.  While my mindset was fixated on creating a UI from scratch, they were all about reuse.  And why did they never mention this to me, allowing me to create a whole deck of virtually useless wireframes? Well, for the simple reason that I never asked.  If I had taken a developer perspective on my design, my starting point would instead have been to first work with developers to research what available frameworks are out there, and then if we agree on one to use as a starting point, my design exercise is instead transformed into a customization exercise.

Another great example of developer thinking is reflected in test-driven development.  In that model, a piece of code is the user requirement. In other words, instead of writing a traditonal list of text requirements, you instead make the underlying intent of that requirement manifest in the form of code.  In other words, since a well-formed requirement should be unambiguous and testable, why not represent it as an actual piece of code that inherently will be unambiguous and will simultaneously be what performs the test of the requirement that it describes?  This type of thinking can be really really hard for UX folks to understand.  But I think if they were to spend less time doing wireframes and more time actually building stuff, it would suddenly make a lot of sense, and the whole design effort would be better off because of it.

What is Pair Design?

The idea of Pair Design is, of course, based on the concept of Pair Programming.  But it is more a hybrid rather than a wholesale translation of the model.  Here, instead of having two people with the same skill sets collaborate side-by-side, we are pairing people with different skill sets and perspectives.  In other words, the front-end developer might pair with the graphic designer and build the grid created during the sketching session, the graphic designer ‘debugging’ it from a visual design perspective, while also being made aware by the front-end developer of the range of dynamic potential of the grid by way of iterating between building and seeing it evolve in a browser.  Or the front-end developer might pair with an information architect or interaction designer, instead focusing on issues such as content structure and flow.  Who pairs with whom will be specific to the project and team.

Pair design might be a bit weird for some team members at first, as they may be  uncomfortable about having someone else watch them work.  One way to mitigate this is to start by pairing in front of the application used by the person least experienced with this method (or with Agile methods in general), e.g. OmniGraffle or Visio for an Information Architect, which is their home turf and comfort zone.  Then, once some detailed design work has been completed, or whenever makes sense, move to the developer’s screen and begin the work of translating the work completed so far into code, and go from there.

This activity can be a powerful team-builder, allowing for forming stronger bonds across disciplines, and reduce the quantity of unnecessary and redundant artifacts.  One great example of an artifact you might be able to skip is wireframes.

Pair Design offers an opportunity to skip wireframes altogether

One of the biggest problems with wireframes is that they inherently communicate a design idea in the form of a page layout.  Often, the layout is created by the person creating the wireframes without having explicitly discussed it with other team members, particularly the visual designer, which can lead to one of two equally bad scenarios.

Bad Scenario 1: The visual designer takes the lazy route and simply replicates the layout created by the information architect in the wireframes, which very possibly may have been produced with no formal understanding of page grids, meaning that the entire visual layer of the application will be hampered by a sub-standard layout.

Bad Scenario 2: The visual designer completely disregards the layout in the wireframes and produces a comp with elements organized in a completely new way.  This is almost certain to aggravate and confuse clients or non-technical stakeholders,  who understandably have been evaluating the preceding wireframes not purely as representations of an information architecture, but holistically.

I’m never quite sure whether to laugh or cry when I hear IA’s ask clients to disregard the layout in their wireframes, since it not only places an incredible cognitive burden on the client, but also really makes no sense.  How information is represented visually has meaning in itself (e.g.  in terms of proximity, size, visual hierarchy, etc.) So we really are asking of our clients a near impossible task and instead only admitting to a fundamental flaw in the concept of a wireframe, in that it purports to somehow separate information architecture from visual design, when it in fact does nothing of the kind.

Better to instead present a layout that in fact is one developed by the team as a whole.  And a great way to do that is to skip the wireframe (or use it strictly as an internal artifact) and instead present either early versions of a design comp or skeleton page builds.

Pair Design can help to dissolve the Us/Them divide between Tech and Creative

Too often, Tech and Creative see themselves as separate camps within a design team.  One common reason for this is that a waterfall method effectively creates this separation by virtue of the two roles being separated in the project plan (design first, production  second), and separated by one party handing artifacts off to the other.  By physically pairing these roles, you are able to bring roles in closer contact, and have them looking and talking about the design together.

Another great benefit of Pair Design is the potentially powerful psychological bond that emerges between two people working in isolation from the larger team.  There is just something about two people sitting in close physical proximity and looking at and conversing about the same problem that seems to transcend their respective disciplines.  Compare the dynamic of having a visual designer email a Photoshop comp to a front-end developer to that same person instead sitting next to the developer and talking about the ideas underlying their comp and the two then working together to evolve the design solution.  For example, a design may look great to the visual designer when viewed inside their graphics application, but when the design is rendered in a browser, it may look significantly different. A great example of this is how fonts are rendered in a browser.  I.e. fonts may look nicely anti-aliased on PhotoShop, but when the browser displays them, not so much.

A possibly even more powerful example is that of rapid prototyping using frameworks such as Jquery.  Rather than have the interaction designer toil away at some time-consuming illustration of a dynamic feature, the interaction designer can instead pair with the front-end developer and actually prototype a variety of dynamic options on the fly.   In fact, I regularly talk to interaction designers who have no clue that there are a lot of dynamic features, particularly those available in standard UI libraries, such as ui.jquery.com, that a front-end developer probably can prototype faster than the interaction designer can spec it.

So is this to say that the entire solution should be created in pairs or that there is no need for any wireframes?  Absolutely not.  The ideal is likely to be an even balance of team members working separately and in pairs.  More importantly, it is about an underlying mindset of not defaulting to creating artifacts in isolation but rather defaulting to creating artifacts by way of conversation.

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.

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:

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.

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.

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:

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:

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.