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.

1. 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.
2. 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:

1. 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.
2. 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 doing imaginary design 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.

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.

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? Should we use tabs or a list of links for navigation?  What are the appropriate labels?  Should the search field watermark just say “Search…” or something else? 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 burndown 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

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.

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.

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.

Enjoy!

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.