110 thoughts on designing user experiences

In my previous post, I talked about how applying grid focus to a sketching activity can allow for improved integration between the work of UX, Visual Design, and front-end developer disciplines. One natural follow-on activity to having explicitly defined or sketched out a page grid during sketching is to then work on more detailed designs in pairs, i.e. to Pair Design.

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.

{ 4 comments }

This is a slidecast (slides with audio) of the talk “Agile for the rest of us” I gave at the 2009 IA Summit.

Enjoy!

{ 0 comments }

The iterative design methodology is, in my opinion, the most effective and powerful approach to designing websites and applications.  This is particularly true when comparing it to the more traditional waterfall methodology.    While the methodology may be old hat to our more mature cousins, such as industrial designers, it seems many of us in the UX community are only now discovering this technique.  (At the same time, there are aspects of working iteratively when designing digital products that are unique compared to fields such as industrial design.)  So, what is iterative design all about, and what makes it powerful?

What is Iterative Design?

Iterative Design is, at the surface level, really only different from the waterfall methodology in one way. Instead of specifying the entire application before building it, one fully designs and builds one part of the application, and then uses that and previously completed units as a basis for future design and production.  In other words, iterating is designing and, more specifically, understanding what one is designing through actually creating it.  Alistair Cockburn describes it as “learning by completing” (and distinguishes it from incremental design, which is about adding new elements, which one can choose to do iteratively, while iterating is about reworking and refining.)  Perhaps most importantly, an underlying principle of the iterative method is that until you have actually built what you are designing, you are not going to be able to fully understand it.

So, this one change, of starting to build earlier in the design process and continuing to build as part of the design process, of folding the work of what one in waterfall might think of as “production”  into the design process itself, can have a cascading effect on the entire design effort.  This can include how your team members are resourced for a project and who works with whom and when.  More importantly, it can also empower your team in ways that simply are not possible when working in the more linear waterfall model.  For anyone practicing one of the various flavors of Agile, this will all likely look quite familiar, and for good reason, since everything that converged under the Agile umbrella really are just different flavors of  iterative (as well as adaptive/lightweight) development methodologies.

There are many great reasons for going iterative. One of the most significant is the ability to discover design problems earlier and thereby reduce overall project risk.

Discover Problems Earlier

One of the greatest threats to any design endeavor is discovering design problems late in the project lifecycle.  The later you make the discovery, and the bigger the problem, the greater the risk to your project.

Some years ago, I worked on a product which was to allow people to maintain and share large policy documents.  We spent hours whiteboarding and brainstorming solutions, regularly presented sketches, wireframes, and comps to users for feedback, and produced detailed wireframes and functional specs. Everything was going swimmingly until time came to actually implement our idea.

As it turned out, the time required to save the fairly large documents that users needed to work with in a browser-based application was, at a minimum, several minutes.  Actually, it was more like 15-20 minutes.  In the world of user interfaces, this is effectively an eon.  Because we were so far along in our project, and had already made several fundamental design decisions, such as deciding to make the application fully browser-based, our options for addressing this issue were quite limited.

We were forced to go with a solution that we knew would be in conflict with how our users actually worked, breaking up the document into smaller pieces, while knowing that our users in fact tended to  make edits or move content across the entire document. This design change would therefore likely reduce the overall value of the product. In other words, the fact that we discovered the problem so late ended up making the overall product far less appetizing to users and therefore less competitive in the marketplace.

Had we taken an iterative design approach, however, this issue would have been discovered much sooner.  Instead of defining the design solution for the entire product before actually beginning to build the product, we would have only created a high-level design of the application and then fully designed and built a skeleton version of that, and then evolved the design based on what had been built.

We could also have chosen to build the application incrementally, i.e. building it in different units, and then iterating on each of those units.  By unit, we are usually referring to some natural grouping of functionality or application entity.  In the case of this application, the document editor would have been such a unit, and would also have been deemed the top priority unit (as it is the core function of the product), and therefore built out first. In doing so, by actually testing our solution with real code, we would have discovered this very technology-specific issue almost immediately.

More importantly, because we would have been at a far earlier stage in the project lifecycle, we would not yet have made any no-going-back fundamental design choices, and would therefore have a much wider range of options in how to address the issue.

In other words, when designing iteratively, you are able to much more easily adapt and change course in response to the unknown or unexpected, in contrast to a waterfall model, where you are much more locked into a specific design direction once production is underway.

This is of course not to say that iterative will allow you to adapt and make big changes up until the very end of the project.  Instead, by starting to build earlier, and discovering big issues early, you radically reduce the chance of making show-stopper discoveries late in the game.

Get Reliable User Feedback

When presenting sketches, wireframes, comps, and clickable prototypes to users for their feedback, you are effectively asking them to imagine how the product will work, to prototype it in their mind as it were, and then provide feedback on what they are imagining.  This is not always a bad thing; in fact, during the early stages of  developing a design idea, it is probably preferable to present something rough to users, inviting them to interpret your idea more widely and also to feel more comfortable rejecting or, better yet, suggesting improvements to your solution.  This is a fundamental reason why we sketch.

The problem is the amount of time that passes between that activity and actually confirming or denying whether or not that thing in your head really is a good idea.  In the waterfall methodology, the time that passes between those two activities can be a looooong time indeed. More time between conception and validation of an idea means increased risk.

Problems begin to emerge when we are asking user to review the ‘real’ solution.  If we present that solution in the form of wireframes, we are placing an incredible cognitive burden on the user to try to imagine the actual product based on looking at one or more static drawings. Talk about Making Me Think! Even if we create a clickable prototype, there is still a large amount of cognitive overhead left to the user. This can include anything from being aware of issues such as page refresh (e.g. a page may not refresh when clicking on a tab in the prototype, but may do so in the real application) to the range of idiosyncrasies of widget controls to the absence of real live content.  As applications become increasingly complex, this potential cognitive overhead will continue to grow.  And the more cognitive overhead we burden our users with, the less reliable their feedback.

In the iterative model, however, the definition of what is and what is not a validation of a design solution is quite simple: Everything that is not actual working software is just a sketch, an increasingly refined idea.

In this model, we have an actual build, a unit of the actual application, that we can present to stakeholders and allow users to interact with and respond to.  When presenting users with something that actually works, they can focus on the activity your product is intended to support, and give you feedback on that.  Additionally, technologists can validate their code (as well as learn from and improve upon it when working on future iterations), while visual designers can evaluate their look and feel as rendered by an actual browser.

Spend less time documenting, more time designing

In a waterfall-based methodology, an incredible amount of time is spent creating and maintaining documents that describe the design solution, from wireframes to functional specs and on and on.  As the software systems we are designing become larger and more complex, more time is required to describe their design in ever-greater detail.  Worse, once we begin to discover issues with our design solutions, we have to go back and update these tome-size artifacts, which will take up even more time if we are further along in our process and multiple artifacts need to be updated.  And to add insult to injury, since there really is no standard for the types of documents we are creating, we have to spend even more time on these documents adding legends and other references explaining the meaning of stuff in the very artifacts intended to explain what stuff means.

This, in my opinion, is a recipe for disaster.  For one, it tends to become increasingly impossible to keep all the documents up to date, which means they can’t be relied on, which means all the work you put into them may be for naught.

And second, it seems that the more you document, the less people read, for the simple reason that specification documents are inhumanly boring and require a lot of brainpower on the part of the user to interpret and convert their content into the actual solution.  So what ends up happening is that designers and developers sort of skim through all your painstakingly created artifacts, creating something that might be close to what was specced, but rarely exactly what was specced, which seems to make the entire arduous effort sort of self-defeating.

In the iterative model, the approach is to instead leverage the technology itself as a specification platform and to thereby spend much more time being engaged with the actual product, with the actual design, rather then being bogged down with huge artifacts that ultimately having nothing to do with the product.

The idea of using the code itself may sound strange to the non-technical reader, but if you think about it, what is code but nothing more than a set of instructions? And while those instructions may be gibberish to you, they are highly meaningful to developers.

Now, this is not to say that we don’t create any specs as part of an iterative model; the real difference is that the specs that are maintained are only those that are for new design, while as soon as something has been built, the corresponding spec is archived, eliminating the potential for redundancy (and the inevitable accompanying inconsistency) of having both a spec and a build.

If you’re new to iterative and have really only worked in a waterfall process, Iam guessing that it may be difficult  to wrap your head around this concept. But hopefully this (somewhat meandering) post will help you get underway.

{ 2 comments }