126 Thoughts on Designing User Experiences

Menu

Category Archives: Process

UIE just published this podcast, where I have a great discussion with Jared Spool about how I’ve applied Agile thinking and values to UX practice. Here’s a sample from the beginning of the podcast, where I talk about how this thing we call Agile is really historically upside down…

Jared: …it feels to me sort of like an onion, in that you’re always seeming to peel things back, and at the core of it are these Agile values that really, I think, speaks a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.

Anders: Yeah. So what’s interesting and maybe confusing for people who aren’t aware of the history is that even though the “Agile Manifesto” you know, was formulated in 2001, that was something that was many, many years in the making. And it’s really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term “Agile” was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.

So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It’s something that we can all refer to. We can just talk about Agile. We’re referring to this kind of way of thinking about design in general and software specifically.

In my previous post, I talked about how starting to build earlier has a cascading and transformative impact on the UX practice. One big change change driven by starting to build earlier is that of condensing up-front design work down to Just Enough. In other words, we go from doing a lot of analyzing and creating a lot of documents, sometimes for months, to committing to start delivering some kernel of the real product within weeks of project inception.

Once some kernel of the working product has been built, there is a fundamental shift in the working relationship between design and development. We move from the traditional assembly line hand-off model to something more akin to a theater production, where we are in a continual state of iterating on something real, from reading the script to acting it out in some rehearsal space, to adding set design, costume, and so forth. We are designing by doing rather than designing by describing. This is a concept Robert Austin and Lee Devin describe in wonderful detail in Artful Making, a must-read for anyone interested in elevating their Agile UX chops.

But alas, designing the product while developers are building the product is alien territory for many traditional designers. A UX designer indoctrinated into a traditional approach to UX design, with lots of pre-development design work, lots of exploration and iteration away from those who will actually be building the product, is unlikely to be prepared for the type of transformation of their practice that this change will bring about.

Without an Agile mindset, without an understanding of what it means to iterate not just design in isolation from development, but to instead iterate design with development, which is what we really are talking about here, you are almost certain to suffer some form of dysfunction, such as this horror story relayed to me a while back by a UX colleague:

This whole designing ahead thing is driving me crazy. I’m supposed to have detailed designs ready for the next sprint, which starts in a few days, but I can’t get the developers to stop coding and spend some time whiteboarding the UI, because they’re heads down finishing the current sprint and want to match or beat their velocity from the previous sprint. So now, the same thing that happened last sprint will happen this sprint: the developers build what I give them, which ends up being only half-baked in terms of UX because we didn’t really collaborate on it and because I had to rush my work to not fall behind, and yet they call it Done because they built everything I put in the wireframes. I can’t keep up. I’m just one UX Designer and they’re a whole team of developers. Man, I miss the good old waterfall days…

Does this sound familiar? The lone UX’er having to crank out wireframes to keep the dev team busy, with the resulting product perhaps being impeccable at the code level, but half-assed at the experience level? This phenomenon, sometimes referred to as “Feeding the Beast,” is what I think of as the dark side of Designing Ahead, which has become a relatively standard pattern among teams integrating Agile and UX.

The dysfunctional Feeding the Beast phenomenon occurring when waterfall thinking is applied to Designing Ahead.

The idea of designing ahead one or more iterations, of working on the UX for iteration 6 while developers are working on iteration 5, has emerged as a common practice in Agile UX circles. One of the originators of this pattern are Desirée Sy and Lynn Miller and this now-somewhat-famous paper they wrote. Don’t get me wrong: the issue is not with Designing Ahead per se. Desirée and Lynn and the folks at AutoDesk have applied this approach and been very successful.

The issue is with applying the pattern with a waterfall mindset rather than with an Agile mindset, which is what leads to much of the dysfunction. Top-most among them, in my experience, is thinking that designing ahead means designing alone.

Don’t Confuse Designing Ahead with Designing Separately

This is a great example of a waterfall mindset sneaking into an Agile approach. Just because there is a need to do some UX design ahead of the iteration work doesn’t mean you should be doing that design separately and away from other team members. So, let’s be very clear:

It is not the UX designer who should be designing ahead. It is the team that should be designing ahead

“But wait a second,” I can already hear a UX designer asking, “how can the whole team be designing ahead if the developer-part of the team is busy building for the current iteration? How can they be doing two things at once?” The problem with this question is one of misunderstanding what type of work is (or should be) done during an iteration. It makes the assumption that project iterations are discrete units of work with no overlap from one to the other.

As Mike Cohn explains in Succeeding with Agile, iteration work should include not just delivering value by the end of that iteration, but should also include planning and preparing for the next iteration, to ensure that it too is able to deliver value. And that preparation should include UX Design.

Bake UX Design into the Planning and Preparation for the Next Iteration

This means that the team should be committed not just to building for the current iteration but also designing for the next one. Certainly, the UX designer may be spending more time than the developers on this, but the developers are continually and actively engaged, reviewing mockups, providing feedback, showing the UX designer what they currently are building, to allow that to inform the design work being done for the next iteration.

Remember, adopting an Agile UX approach requires transformation not just on the part of UX designers, but also on the part of developers. That means that developers who may have been of the mindset of focusing on code quality and velocity will need to broaden their thinking to include product quality, where user experience plays an evermore central role.

Another common problem is that of trying to have a “finished” UI design by the time the iteration begins.

Design at the Right Level of Detail at the Right Time

Don’t try to figure out every last detail in the preceding iteration. Get the big conceptual ideas figured out, such as the user flow or any unusual UI patterns, etc., but save atomic-level design for the actual build iteration. For example, let’s say you’re designing a domain-specific registration process. For the screens that deal with the unusual domain-specific stuff you may go into a lot of detail, while for generic registration stuff, like “address” or “payment info,” you’d only define it roughly. Then, during the iteration, you may actually sit with the front-end developer and work on the detailed stuff, such as error messages and character allowance for form fields.

In Fact, Strive to Make Designing Ahead the Exception

In my opinion, the goal should always be to complete the UX design of what you are building in thesameiteration that you are building it in and then move the design work to an earlier iteration only if needed, in which you have virtually eliminated hand-offs and document waste. Yes, it will in many cases not be possible, but it is the mindset that matters here, to be thinking of that as the ideal state. There are two factors, in my opinion, which will require the team to forego that ideal: 1) Inexperience collaborating and 2) A high degree of design innovation.

Reason 1 to Design Ahead: Inexperience Collaborating

The idea of integrating design work with development work is, as I mentioned earlier, uncharted territory not just for traditional UX designers, but also for many Agile developers, who often are used to doing all the design work on their own, or just being handed some UI mockups to build from. This means that Designing Ahead requires teams that are highly adept at collaborating, teams that, for example, understand how to use light-weight rapid communication methods. If you’re new to this form of intensive collaboration, getting to that point will require a few training rounds and some good coaching.

Reason 2 to Design Ahead: A High Degree of Innovation

The more innovative the design work, the more groundbreaking or otherwise unusual it is, the more time you will likely need for upfront exploration. On the one hand, be mindful of the high level of risk attached to pursuing a highly unusual and non-standard user interface. At the same time, innovation is part of the UX game. Try to treat the innovation work like a UX spike, i.e. a short and intensive exploration. Just don’t turn it into an excuse for doing weeks or more of mockups and sketches. The goal should always be to find the shortest path to start to confront your ideas with something real.

In my previous post, I talked about how shifting your UX practice to an Agile approach first and foremost requires a change in attitude. But changing your attitude can be much easier if you have a clear and concrete goal you are working toward. And one of the most common challenges I come across when talking to UX designers transitioning to Agile is that they do not have a clear understanding of the journey. It is not clear what is different and what remains the same. It is not clear where to begin in making a change.

So let’s simplify things. Let’s reduce your Agile adoption down to one change, a single clear goal, the one change that—in terms of process—lies at the very center of everything else that changes when going from a traditional approach to an Agile approach…

Start Building Earlier

If you are not starting to build earlier, then you are probably not practicing Agile. At the same time, earlier is a relative concept. So, within whatever circumstances you find yourself, look for the shortest path to start delivering real working software. Commit to start delivering a working product at the earliest responsible moment.

In other words, go from this…

a highly simplified version of a waterfall approach, in which virtually all design work is done before building, to this…

…what I like to call a Step-Ladder model of an Agile UX lifecycle, in which we do Just Enough design up front and then iterate on the design in parallel with development. (The parallel design portion, btw, has become a relatively established pattern; our focus is on when that pattern begins in the project lifecycle.)

Yes, adopting Agile is about much more than this one change, but particularly from a UX vantage point, this shift has a cascading and transformative impact. I like to think of it as The One Change that Changes Everything. Why? Because virtually all other changes that occur in the UX practice when adopting an Agile approach flow out of this one change.

The first and probably most fundamental change to flow out of starting to build earlier is that of chopping your up-front design phase down to a fraction of what it might be in a traditional model to allow for establishing a foundation of working software, and then evolving the rest of the product on top of that foundation. In other words, we go from Big Design Up Front to Just Enough Design Up Front. So how do we do that?

There are two key changes to focus on here: Rapid and Rich Communication, and Just-In-Time Detail.

Rapid and Rich Communication

Perhaps the greatest weakness of a traditional UX model is the slow pace at which ideas and concepts are communicated. While the What—design concepts and principles—may be as sound as ever—the problem is in the How—the methods used to evolve and communicate them.

The time it takes to create a conventional design document, be it a functional specification, or a set of use cases, or deck of wireframes or whatever, is usually measured in days or weeks, or sometimes even months. That means there is less time in the overall project lifecycle for development, which in a software context really just is a continuation of design exploration. More importantly, it means that there is less overlap and iteration between creating design artifacts and exploring them in code, which in turn degrades overall product quality.

There are two main reasons why traditional UX artifacts are soooo slow to create.

They are created using a document-centered engineering-like model, in which it is assumed that the document will be the primary conveyor of information. That works well for domains with greater design stability, such as bridge-building, but is incredibly wasteful for domains with a high level of design volatility, such as software.

They are created mostly in solitude, meaning that there is a built-in time delay between the point of design creation and design vetting with other team members. Spending so much time separated from other team members also perpetuates the Us/Them mentality, which makes being a UX designer less rewarding and makes it harder to integrate UX into what other team members do.

In an Agile model, communication is rapid and rich. This can be achieved with conversation-centered documents and collaborative design.

Conversation-Centered Documents

In contrast to Waterfall time, Agile time is mostly measured in hours and minutes. Agile documents are conversation-centered. We use artifacts such as post-its and whiteboards that are able to cope with the highly volatile nature of information in the software domain. Documents quickly grow stale, especially in a software project; conversations are always up-to-date. Documents therefore exist primarily to support discussions between team members, which are expected to be the primary conveyors of information.

In this context, documents serve two main functions:

The Conversation Placeholder: An example of this is a story card. It is a placeholder for a future conversation between team members. One can think of the story as the title for that conversation. It contains only a barely sufficient amount of information for that conversation to take place. Often, the details, the actual story, may change over time, but the title does not need to change.

The Conversation Supporter: An example of this is a diagram, sketch, wireframe, or prototype. It is intended to support a conversation happening now. For example, it could be used by a User Experience designer and a front-end developer pairing on a detailed design. It exists to convey information that would be challenging to convey with a conversation alone. By using rapid communication artifacts, such as physical sketches, the conversation supporter can often be updated during the conversation.

Collaborative Design

Sure, everyone needs a bit of alone time on occasion, but in an Agile model we strive to create design artifacts as a team during team meetings, or strive to do detailed design in pairs. This eliminates the lag time that occurs when one person designs something and then has to meet with another person to review it and so forth. This is why pairing is so powerful, because you are in a continaul state of both exchanging and vetting one another’s ideas. And if you are doing cross-functional pairing, then you are also doing that across disciplinary dimensions.

This approach allows for creating Just Enough detailed design at the outset. With several team members present during the actual design work, the team can then also establish when the design has reached a point where it is more cost-effective to start building (and in effect design through exploration) rather than continue designing by describing, i.e. with documents. With a Rapid and Rich approach, your communication will be faster and higher quality.

Just-in-Time Detail

Another key reason why the up-front work takes so long in a traditional model is because there is this idea that every design detail has to be defined before any part of the application can be built. But the reality is that you only need a Big Picture design and a Kernel design.

Big Picture Design

A big picture design is any set of artifacts that allows the team to understand what the major areas or units are of the application. From the vantage of pointing of starting to deliver a product at the earliest responsible moment, the key factors to understand are which application units are the most essential to the product and which are most complex or unusual.

A Story Wall (i.e. a collection of story cards organized to visually represent the major areas of the application and maybe also across other dimensions such as priority level or complexity) is a powerful method for representing the Big Picture, but a basic site map with some annotations may also work.

Sometimes you have to get into the details to understand the big picture, so you are likely to also need some other artifacts to understand essentialness and complexity, such as UI sketches or a prototype. The specific artifacts you produce is up to you and your team; what matters is that you only produce the minimum artifacts needed to understand the Big Picture. That understanding, in turn, will allow you to focus on the Kernel Design for your initial release.

Kernel Design

Let’s say you’re designing an auto parts ordering system. Based on your big picture design work, you determine that the most essential component of the application is the ability to place an order. That is your kernel. Without that feature, there is no product. Therefore, that is what you will focus on to design in detail for the first release.

Now, uncovering the product kernel is not always easy. Often, you’ll have clients who say that everything is essential. In those instances, it can be effective to use an Innovation Game, such as Product Box and Buy a Feature, which helps the client envision the end product and forces them to make tough choices and uncover what really is important. In other instances, the choice may be to select the most complex or unusual set of features, to allow for uncovering the unknown or unexpected as early as possible.

Regardless, the kernel must be a complete and coherent feature set that represents some essential product capability. (There are exceptions to this, such as for teams completely new to Agile, who, taking a page from the Cockburn Crystal approach, may want to start their first iteration with a simple set of functionality that allows the team to go through the motions of working this way and boost team morale and confidence.)

While there are several activities I haven’t touched on here which one would likely also need to include in a pre-building phase, such as Domain and User Research, the same principles apply. Leverage rapid communication tools to communicate with team members and research participants (e.g. SMEs), do only a barely sufficient amount of research, and remain singularly focused on beginning the work of delivering the working product.

In a future post, I’ll talk about how the One Change That Changes Everything also cascades into the software delivery phase, in which the UX practice is transformed by entering what effectively is alien territory for a traditional UX designer: working not ahead of but in tandem with developers.

It seems to be increasingly commonplace for there to be a shortage of senior level UX designers, so the ability to extend fewer of them across more teams is likely of great interest and potential value to many organizations. This is an emergent pattern in Agile UX circles for achieving this.

More UX in early iterations, more Dev in later iterations

One of the more common challenges in integrating UX work into an Agile team is the push-and-pull between the good Agile practice of having knowledge and expertise distributed across team members and the desire to have a genius designer just come up with a strong design concept and hand it off to the team, so that the team can quickly get started building.

The latter model seems nice in the short term, but leads to all kinds of problems in the longer term. When developers simply are handed something to build, something they were not part of designing, they are likely to care less about the quality of the experience, since they have a decreased sense of ownership of the work.

And, because they are less likely to understand the thinking behind the overall concept, i.e. why a certain design choice was made, they will be less able to extrapolate it into the atomic-level details they are working on, many of which the overall concept inevitably did not account for. In short, not having the team actively participate in developing the overall user experience vision will lead to a lower quality product.

@johannakoll sketching, photo by Paul Kelly

Teams I have met and worked with are usually eager to participate and own the UX design, but often just need a bit of high-level guidance. What should be the overall user flow? In what way should pages for anonymous users be different from those for users who are signed in? What are some key considerations in designing the navigation? In designing forms? Etc.

The UX Coaching model has emerged as a strong pattern which provides a best-of-both-worlds solution to this challenge. Here, the UX expert acts as a kind of consultant to the team, providing guidance while ensuring that the team is actively participating in the development of the overall vision. Team members are not just reviewing and providing feedback on the design, but are in fact the designers of the user experience.

In this model, the UX Coach plays two main roles:

Visioning: At the outset of the project, the UX Coach helps the team develop a user experience strategy and vision that best supports the overall business need.

Office Hours: During development iterations, the UX Coach is available during regular “UX Office Hours,” which become part of the project rhythm, to provide the team with feedback on their design concepts, to ensure that it remains consistent with the overall vision and in line with the latest UX best practices.

UX Visioning

The specific activities that would be part of developing the experience vision will be unique to each project. Some examples include a Product Box activity and a Design Studio activity. Additionally, it will involve some user research, such as a contextual inquiry, user interviews or whatever makes sense for the current situation. As with the design work itself, the UX Coach would lead the team in how to do this work, but the team is responsible for doing it; they will be the ones observing and interacting with users. Here, the UX Coach does not present design concepts to stakeholders; team members do. The UX Coach does not produce sketches or wireframes or prototypes; the team does. (Yes, they may provide training and guidance regarding the mechanics of creating these forms of artifacts, but they are not producing the actual project artifacts.)

At the conclusion of the visioning phase, which ideally should last no more than three weeks, every team member should have a clear vision of what the product is, why the product is being created, and what the current vision is for what the user experience of the released product will be.

UX Office Hours

With the team now having a clear sense of direction of the user experience, they can begin to simultaneously design and develop the detailed solution. During early iterations, teams are likely to spend a greater part of their time doing design work compared to actual development work. Some developers are likely to feel that they are wasting time on doing user interface design and that it will look bad on their burnup chart. It will be the job of the UX Coach, in collaboration with a ScrumMaster or equivalent team role, to manage this.

Teams need to take a step back and realize that, while short-term velocity may be lower, the overall project velocity is likely to be higher, since iterating between sketching/wireframing and building can happen more fluidly with the same group participating in both of these activities.

As the product begins to take shape, the product itself can more and more become a reference point in the design, with an increasingly smaller part of iterations needing to be devoted to design, allowing for velocity to increase. (E.g. a developer can build a new page template using an existing template but only add one or two new blocks of functionality) This approach can powerfully mitigate the whole “feeding the beast” phenomenon that emerges when UX designers are expected to be creating entire solutions an iteration or so ahead of designers, which really is nothing more than doing waterfall inside of Agile.

These are some key advantages of this model:

Allows a small number of UX specialists to guide a large number of teams

As I mentioned above, perhaps the greatest strength of this model is that it allows for a smaller number of senior level UX designers to lead a larger number of teams.

At the same time, the idea of having one individual work on many simultaneous projects is generally considered an anti-pattern in Agile circles. In a traditional model, because project pace tends to be far slower than in Agile model, working on many projects at the same time may appear to be effective, but the reality is that it creates continual disruption of work and incurs a cost each time the individual switches between projects, since they need to be brought up to speed on whatever developments have happened since they last were working on the project. And with an Agile project, a lot more is likely to have happened in a shorter period of time.

It is a bit like one ball player trying to play on two fields at the same time. It just doesn’t work. But a sports coach certainly can coach more than one team, and so too can a UX Coach lead the UX design for several teams. After the initial project visioning, at which point the coach’s involvement is more intensive, the relationship can then become a recurring part-time relationship.

Facilitates increased UX literacy across the organization

As team members are forced to think about the software experience, in addition to the implementation of the software, they will develop an increased understanding of the relationship between these two dimensions of work. Over time, they will require less and less guidance from a UX specialist, making for an approach to designing user experiences that is more holistic, cost-effective, and leads to a higher quality experience.

Disadvantages

This approach will really only work with very senior-level User Experience designers, who have experience in developing overall experience strategies, are fluent in current best practices, and have experience facilitating group sessions. However, that is no different from the requirements for being a successful Agile coach, which requires years and years of experience in the project trenches, in a variety of roles. The approach is not recommended for junior-level designers, who are likely to be more effective if instead allowed to focus on a single project. There are probably other disadvantages, but I can’t think of any at the moment.

Update: Once again, Joe Sokohl comes through with key insights, pointing out something that was obvious in my mind but I did not state explicitly in the post – the idea of a UX Coach is analogous to an Agile Coach. Just like the Agile Coach is not part of a team but helps the team undergo the transformation from a traditional to an Agile approach, so too does a UX Coach help Agile teams undergo a similar transformation, from UX being a vaguely mysterious notion to something that is just another normal part of an Agile project lifecycle. Thanks Joe!

This is a talk I recently gave at the Delve NYC Conference. The goal is to provide traditional UX practitioners with an understanding of what it means to be part of an Agile team, as well as provide some suggestions for how to make the journey from Traditional to Agile. (For a visual summary of the talk, check out @rayraydel‘s visual notes, or this one from Matthew Oliphant.)

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.

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.

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, 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 within 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.