There Is No Waterfall
Traditional software-development methodologies are not step by step or siloed. In even the worst development process, people aren’t locked into separate rooms to do their work in isolation, then pass fully formed, unchanging documentation through a slot in the wall. As Phillip G. Armour wrote in his article “The Business of Software: Estimation Is Not Evil”:
“The waterfall model was never really a way of working. It was not so much a development model as a management model that allowed a simplified basis on which to track projects. Work was rarely if ever finished on an unambiguous date, while most requirements might have been defined up front others were identified in later phases, and necessary reworking occurred throughout the life cycle all of which contradict the naive model assumptions.”
This is my experience also. Only bad teams failed to collaborate or work iteratively. Even if some clever manager overreached and tried to manage everyone into bad choices, the various disciplines would meet secretly and coordinate their activities. Everyone was iterating all the time. For example, spiral is just one older development methodology whose purpose is to improve products throughout the development lifecycle. Figure 1 illustrates how spiral development works.
Other development processes tend to be similar. Even when there are distinct phases, everyone—including whoever will eventually maintain the system—is invited or even required to participate. Plus, many phases overlap or people continue working in a monitoring role because of the near impossibility of nailing down a design in isolation.
Which brings us to how to integrate User Experience into these processes. Easily and naturally, I think. When serious software developers or architects refer to design, they often mean software design, database design, or other technical design efforts. While teams often give such efforts short shrift today, they are crucial to building a reliable product that does anything like what is expected.
Quantifying User Needs
This confusion of terminology might be an issue. If we mean different things by design, how can we work together? Well, I don’t think we mean different things. UX design is about building systems, too. We just include users as part of the system and acknowledge that they have quantifiable needs and constraints.
It’s crucial to define the user as broadly as possible. Not just all the types of end users who will use your product, but internal users like administrators, content creators, and the people responsible for system maintenance. Whether you’re porting legacy systems to new platforms or creating all-new technologies from scratch, beyond the digital technology, there are business processes and objectives that you need to address as well.
When you look at User Experience in this way, suddenly everyone in the business—maybe even the Engineering team—will find that your role makes sense and is valuable. This is especially true if you, as the UX designer, also take the time to understand technical constraints and consider the client’s needs, as well as the user’s needs. If you do, your design work will naturally be in sync with the technical specifications. Because of the analytical nature of our work, UX professionals can become the most valuable members of their teams early on. And this is when it is easiest to do our work anyway.
User Experience and the Development Process
The only challenge, then, is the development process itself. Within the past week, I’ve seen agile experts come in who totally failed to understand what User Experience does. Even after I’d explained the role of User Experience a few times, their assumption that we’d do UI design after the stories were set persisted. They even thought we should just “clean up the UI” after the first round of development work on a feature was complete. Even worse, their view was that, if we insisted on doing some overall, holistic design up front, we’d be breaking their process and thus, committing the ultimate sin: not collaborating.
In an exchange on Twitter a while back, Brian Rieger responded to my tweet as follows:
“I find ‘agile design’ discussions most curious as I was never aware that design (as I was taught) could be anything but agile.”
Aside from a few managers, process coaches, and developers who were raised badly, most project teams will at least give you leeway to explain your role as a UX professional and what you will do to help a project. So, what can you do to overcome such biases?
These days, more often than not, I say that I am an ecosystem designer. My job is to discover, synthesize, and balance all needs and constraints, as shown in Table 1.
Organizational time and budget
Organizational objectives and key results
Technical feasibility and environments
Legal, regulatory, or process requirements
The environment in which users operate
And how do we do that? If I had to nail this down by defining a few key guidelines, I’d say:
- First, don’t draw.
- Gather and understand.
- Design ecosystems first.
- Hold, look, tap, and connect.
- Annotate, describe, and explain.
- Evaluate and validate.
Before I get into discussing each of these, I want to emphasize that they really are not steps in a process. Instead, they are actions or behaviors that you employ repeatedly—or even continuously—throughout a project. These are things that you do iteratively. For example, you do the first of these whenever new information arises, not just when you first join a new project.
First, Don’t Draw
I came to understand these things about the role of User Experience in the development process not through philosophical introspection, but from failing, badly. By nature, I am of the “genius designer,” decision-making type and get pretty good results by relying on gut instinct and experience—though I hate some implications of this term. I actually used to interrupt client’s explanations of their needs and come up with pretty good solutions on the whiteboard in a few minutes. But, over 10 years ago, things came to a head when I was the UX designer for a complete redo of the Sprint Web site.
I created a very high-level sitemap—before the term information architecture (IA) had really made it to my brain—and a set of page templates that complied well with both branding and best practices. Then a very good project manager arranged for us to be in a room with each of the product owners in turn. For six months, sometimes for 16 hours a day, I worked with them, drawing each of the site’s hundreds of pages on the template printouts—working section by section and drawing in pencil, as shown in Figure 2.
Then I translated these drawings into Photoshop mockups. A few weeks into this part of the process, it was clear that this approach was insane, and as soon as I was finished, I began developing a better process. This all happened before the UCD chutes-and-ladders chart existed, so there was nothing that I could follow. Figure 2 shows my old approach, designing pieces in isolation, page by page.
Recently, a project experience reconfirmed that page-by-page and feature-by-feature design is a terrible approach. I took over a project from someone else, with no time to start over. The previous agency was a Photoshop-centric, comps-only sort of organization. The client was sure that I could do a great job by picking up where they had left off, so insisted that we just keep going. So I did as they asked—though I did make some half-hearted attempts to diagram the process and enforce consistency. And the resulting design was pretty, fun enough to use, and moderately praised—at first. Then people began noticing issues—for example, that there are fully fifteen styles of modals, interstitials, and popups—that existed for no other reason than that we had designed everything on the fly, to meet specific needs that had arisen at the moment.
When I take some time to listen and think, I always come up with better solutions that are easier and cheaper to build and maintain. Always do this—and insist that your clients allow you to do this. It will make clients perceive you and your UX team as more friendly, and you will get more work when others come to you to improve their products.
Gather and Understand
So, how should you listen? Formally. There are lots of bad processes for gathering information. For example, the traditional brainstorming that we were taught in grade school is a terrible way to find out information. In brainstorming, we are always told that there are no bad ideas, but that’s not true. Aside from there being plenty of bad ideas, what is actually good are constraints. Anyway, we’re rarely asked to come up with solutions to a raw problem. Usually, we already have a bit of direction going in.
As early as User Experience typically engages with projects, usually someone else has already had an idea—in my experience at least. Often, it’s a variation, twist, or improvement on something that’s been around for years or even decades. So the first thing we do is get the whole team together. They have a lot of very relevant knowledge in their heads.
Annoyingly, it’s inside their heads. Be aware people are bad at analyzing and sharing what they know. You cannot just bring them into a room or sit down for lunch and get that information from them. However, there are some techniques that work well in extracting that kind of information, enabling you to find really interesting answers as a result. One way is to visit the people in their own environment. Ethnography is actually the science of observational research, but just bringing your team to a real environment like a home, repair shop, park, or store can encourage conversation and recollection. Figure 3 shows a team visiting a Hallmark store to explore with their clients why legacy products are arranged and labeled in particular ways.
Most of my information gathering is even more directed than this. Over the years, I have learned to ask these four core questions about any product:
- What is the product?
- What is its one main purpose?
- What one problem does it solve?
- Who will use the product?
You can gather this information in several ways. I have successfully gotten answers by simply asking the questions very carefully on phone calls or in email messages or online surveys. By far my favorite method of doing this is what, for years, I had simply called the Post-it method. Many people call this affinity diagramming. Recently, I found out that this method has got a formal name, the KJ method, and was named for its Japanese creator, Kawakita Jiro.
In this method, you gather the project team—and everyone else who has the knowledge that you need—in a room and ask them to write information on cards or Post-its, then organize them as a team. Just telling people to work together and giving them tips on collaboration goes only so far. This is one of those tricky methods that intrinsically makes people work together to come to a common understanding of an issue and agree on the answer.
Don’t Just Check Off This Step—Evolve Your Design
It is important that you conduct exercises like this differently from the way you would a team-building exercise. You don’t just meet, run through the steps of the exercise, then all high-five and move on. During design, apply the data that you obtain from these exercises. Your design should evolve seamlessly from one step to the next.
This sort of exercise results in a small number of fairly well-described features. For agile teams, epics and perhaps user stories could emerge from this exercise. You should do this exercise as early as you can—before embarking on any development process. This is about understanding the customer and the business goals.
Another key outcome should be a set of objectives and key results. This lets you formally quantify success so you can recognize it later on, as well as clearly define a business’s actual goals.
Know Your Audience
Creating personas is a great way to understand how people will really use your product. Personas can be indispensable later on, when you’re trying to understand why actual users are running into issues.
One of Diane Jacobsen’s clients once responded to her expressing the need to get this sort of data as follows: “Don’t do that early fooling around stuff; start with phase three!”
But I won’t lay the blame only on clients. The classic UCD processes are so time consuming that I know few designers who bother to create formal personas. This is not just a problem of perception either; I have worked with teams who spent over 6 months creating personas. The need to abbreviate this process is about more than meeting demands for greater speed; the world may change by the time your team gets those personas done.
You can shortcut this process by completing your user interviews and personas in only a few weeks. Even better, you can get a pretty good handle on your audience in a matter of days. Presumptive personas already exist in the minds of you and your team. You can use the same information-gathering exercises that I described earlier to extract information about personas from the team.
I like to spend some time searching the Internet to flesh out these personas further. For professional users, I look up things like resumés and job postings. But this doesn’t have to be the end of your process. It can be preliminary work to direct your interviews or ethnographic studies, so you’ll get much more accurate results, more quickly as you proceed with your project.