Originally published on Developer.com, May 12, 2014.
Far too many web site design projects are plagued by continuous – or at least repetitive – changes to mockups, or even worse, changes to the user experience after it’s already been implemented. While seemingly inevitable, these changes are both costly and unnecessary. Leveraging a staged approach to development of the user experience can reduce costs, frustrations, and time.
The process revolves around the idea that you move from the least specific to the most specific user interface while covering both the static – what people see – and the dynamic – how they interact. The process outlined below is designed to continuously elicit requirements and improve understanding earlier in the process – with less investment.
Projects that attempt to skip the steps outlined here often go directly to the mockup step and end up in countless iterations because there’s a lack of clarity about what the end goals are. This lack of clarity makes the mockup the virtual dog chew toy, as one group struggles to move the mockup closer to their vision. Ultimately, another group sees the move as moving away from their vision and they attempt to pull it back. By progressing through a rational design approach, the unnecessary work of continuing to develop iteration after iteration can be eliminated.
Goals, Requirements, and Use Cases
Most projects start with a goal that everyone knows. However, all too frequently that goal is too imprecise to be converted into a real vision. The more precise and clear the goal, the easier it will be to design a user experience. While goal setting and visioning are beyond the scope of this article, they’re important components of the process.
From the goals spring the requirements and use cases for the project. While the requirements or use cases don’t have to be “done” before the user experience starts, the more you know about what the solution should do and how it’s expected to do it, the more you know about how the user experience should – or must be built. The user experience design process will likely influence and also be influenced by the requirements and use case capturing process.
Though listed here as the start of the process, requirements and use case understanding typically evolves as the solution that’s being specified gets written down on paper and people begin to really understand what they’re asking for. Our brains are subject to faults where we believe we can “have our cake and eat it, too” – assuming that a given fact is both true and false at different points of evaluating a design. Writing things down and making them concrete makes it more clear exactly what is being built.
Wireframes
The first step in the development of the user experience is to create a set of sketches that approximate the location and amount of space allocated to different uses. The sketch typically takes the form of a set of rectangles where the rectangles indicate different relative portions of content and the location of key controls and navigation. Wireframes are an important step in the design process because it forces everyone to get on the same page as to the relative importance of different aspects of the web site based on both the placement of controls as well as the amount of screen real estate devoted to the area.
Wireframes are often criticized as being abstract and lacking the detail necessary to engage stakeholders in what the end result will look like. This is a fair criticism but is balanced with the awareness that by focusing on the location of the boxes and their size, the feedback related to importance is separated from the feedback about different user experience elements. This makes processing and responding to feedback much quicker and easier.
Storyboards
Wireframes are a great start, but they’re a static picture of the web site and don’t convey how users get from one place to another – or how they complete a use case. Storyboards make those connections. It’s much like the difference between a picture and a movie. A single picture can show you what the user should see – but not how the user can interact.
Storyboards are highly effective at helping to discover places where the user experience will break down because it’s difficult for the user to navigate to where they are supposed to be. Storyboards are the collection of miniaturized wireframes along with some arrows or connecting text to describe how a user moves from one place to another in a use case.
One key to building storyboards is to make sure that you remember to do the negative use cases as well. That is – you want to also handle the use cases where there are problems – not just where things go well. Specifically mapping out negative use cases has the benefit of exposing limitations. For instance, consider a storyboard for a user who has forgotten their password.
It’s quite normal for revisions to be made in the wireframes based on the work done during the storyboard phase. Like the other phases in the project, wireframes and storyboards interact.
Mockups
Once the wireframes and storyboards are done it’s time to add the muscles and skin to the skeletons created with wireframes and storyboards. Mockups, or design comps as they’re sometimes called, are the first step where clients get to see what their final solution may look like. It’s the time of graphics, colors, and typography. Because in this phase it can feel like things are finally starting to be real, clients frequently try to start with this phase.
While the phase is necessary to engage the client in the process – because it is beginning to feel real – it’s often an area where subjectivity of preferences starts to raise its head. Because of this, a greater degree of skill with meeting facilitation will be necessary during this phase.
Prototypes
Mockups are the fleshing out of the wireframes, but prototypes are the fleshing out of the storyboards. There are several different kinds of prototypes that can be created, ranging from a fixed prototype, which requires that the user follow a predefined path to an interactive prototype built on the targeted platform but without any of the backing logic or architecture. The goal of most prototypes is that they are discarded – however, those built on the platform may continue to be used.
Prototypes allow clients the first opportunity to see what the final solution should look and behave like.
Iterations
The final step is the actual development of the solution in the platform. While it’s possible to do a single iteration and a final deliverable of the user experience after the preceding process, it’s generally preferable for the development to be done via an iterative or agile software development process. The iterations should be largely stable from a user experience point of view, but the evolving support of features in the system allows the client to validate the user experience for new features immediately.
Conclusion
When the process is followed from beginning to end, the understanding of what is being built evolves naturally and the fact that the earliest components of the process can be changed easily allows for this understanding change to happen without substantial impact to the project and without the perception that the project is just thrashing, incapable of moving forward. You don’t try to leap up a set of stairs in one big bound – you make a series of small, changeable steps, which you can build upon until you reach your objective. Your user experience design should follow the same pattern.