Trusting the Process

I am a firm believer that success starts with the statement of work (SOW). An appropriate and attainable SOW determines whether my team of UX designers and researchers get the time and activities we require to fully understand a client’s needs and fashion a suitable solution.

Regrettably, we often work within overly prescriptive SOWs that dictate a solution before we have a chance to understand the problem. One reason projects are poorly scoped is our clients’ discomfort with ambiguity. Clients understandably want to know what they are getting for their investment: Who will be on the team? What will they deliver? How will they deliver it? How long will it take?

But prematurely-fixed outputs confine the value of design strategy. Designers need flexibility to define the solution once they have complete information.

In design school, when a classmate was uncertain about an ambiguous direction, we urged them to trust the process. This platitude served us well as students, but it is not as persuasive in the boardroom. Our clients need more.

In this article, I’ll discuss three methods we use to reassure our clients when trust the process isn’t enough.

Involve clients throughout the project

We encourage our clients to dive in with us to see and understand the intangibles that they’re paying for. Regular client checkpoints throughout a project’s life mean clients can track the progress of a solution. Clients accompany us to user interviews, share work-in-progress and half-baked thoughts, and collaborate to determine the most appropriate design deliverables.

By contributing alongside us, clients can see firsthand what goes into the creative process and how the research inputs lead to the output. There is no big reveal in our work. A rule in our studio is that if the client is surprised at the end of a project, we haven’t done our job.

As human-centered design practitioners, it is essential that the user voice lives on after our involvement ends. It’s not enough to deliver beautiful personas. We need the client to witness the human side of their business.

To bring these points to life, I’ll share an example from a 10 week project we completed in June. This project involved in-person workshops and interviews with an R&D team in a medical devices company. We’ll call them Herchek Medical Supplies for sake of clarity in this article. The project goal was to identify process and technology challenges that negatively impacted the R&D personnel, then to recommend ways to address those concerns.

When we initiated the research, we invited the R&D team leadership, who served as the project’s key stakeholders, to attend every workshop and listen in on every small group discussion. We wanted them to build empathy for their team through firsthand accounts. While they were at first uncertain about the value of being in the room, they were quickly drawn in when they heard stories, complaints, and wants that they didn’t know about.

From the participant side, the R&D team members were happy to have the active ears of their managers. To them, the managers’ involvement proved that this initiative was truly focused on the team and their needs; the managers were walking the walk instead of just talking the talk.

After research wrapped, we presented a summary of our findings to the Herchek leadership at a midpoint check-in presentation. We highlighted user frustrations, shared anecdotes, and explained our intended next steps.

To the managers, the most important content of this check-in was not hearing what had been shared. They were up-to-date on that because they were there! The value to them was seeing how we synthesized what their employees shared and summarized it into themes. Their inclusion helped us to move faster toward developing solutions rather than spending precious project time aligning.

By the time we reached the final presentation for the R&D leadership team, the majority of the audience was familiar with both the findings and recommendations. The most valuable outcome of their continued participation was that we had already secured their buy-in. This early buy-in was invaluable when others who had not been as exposed to the research raised their concerns, and those who had been along for the ride could address concerns, peer-to-peer.

The discussion moved quickly from ‘What do you recommend? Is this the right story?’’ to ‘How will we implement these recommendations based on what we all now know?’’ Because the seed of buy-in had already taken root, the transition to next steps was smoother and quicker.

This example illustrates the importance of involving the client throughout the research. If we, as outsiders, come in, make suggestions, then leave the client without clear advocates, then our work loses value.

Sell the process, not the deliverable

We encourage our sales team—often the first people on our team to meet the client—to sell the process, not the deliverable. We are not a design factory. Previous work is an inspiration, of course, but we treat each project as a new and unique challenge.

With flexibility to create an appropriate solution, we have more latitude to come up with something truly designed for the client that thoroughly addresses their challenge. If the SOW sets deliverable boundaries too soon, then it limits the potential for creativity. This is what sets us apart from other design firms. This is the true value of our client’s investment.

To bring this point to life, I have a cautionary tale. In this case, the goal of the project was to craft a content strategy and governance model for a client’s technology help platform.

A key section of the platform was a content management system with help articles. Users found relevant articles using a search bar. Content strategy was imperative to ensuring search results were relevant and that articles were useful.

The SOW described the content deliverable as a Word document that outlined the content strategy. Therefore, my team dutifully created a document that contained everything the client needed to guide their content strategy.

It included information such as how articles should be titled, rules for formatting, tagging guidelines, and the process for performing a ROT (redundant, outdated, trivial) analysis to keep content fresh.

As we compiled the content strategy document, we knew it was unlikely to be useful. While thorough, it was difficult to digest and, therefore, difficult to apply.

What the client really needed was something visual and dynamic, such as screenshots to demonstrate formatting rules, an editable tag library, and an infographic with rules to identify ROT. If we had pressed for a change in terms instead of obediently delivering what the SOW promised, the client would have gotten more value from our efforts.

This example, and the lessons learned from it, demonstrates the importance of keeping deliverable format open to change until more of the unknowns are fleshed out.

Use structured flexibility to manage expectations

Lastly, we encourage our project managers and sales teams to bake flexibility right into the SOW.

One common misunderstanding people have about the creative process is their belief that it’s better when the sky’s the limit. Not so—constraints are fuel for creativity. When the sky’s the limit, you might spin until you don’t know which way is up. Conversely, with certain bounds established and when we have freedom to fill the box in numerous ways, creativity flows.

Understanding the benefits of structured flexibility, some things in the SOW should be fixed, giving the team a starting point, but there should also be established checkpoints at which to reassess and pivot.

An opportunity to pivot could involve no-cost change orders with the expectation that the team will redefine the SOW once they get in and understand what solution makes the most sense. With an SOW structured to be flexible, both designers and clients have clearer boundaries and expectations.

To illustrate this point, I’ll describe how we scope design-to-development projects into two phases.

Design-to-development projects require more flexibility than projects that end at design or begin with development. You can’t know the development effort required until you know how big and complex it’s going to be—and that comes from research and design.

Although this seems like common sense, I’ve witnessed many failed projects where the number of sprints was predetermined, then the team tries to cram activities into a too-small timeframe. The outcome of this retrofitting is disagreeable for both sides. My team is overworked and frustrated. The client is disappointed and indignant over an unfulfilled promise.

To prevent that outcome, my team scopes design-to-development projects over two phases. In Phase I, a fixed-price discovery phase, we explore functional, technical, user, system, time, and access requirements before writing any code. After Phase I, we convene with the client to estimate the scope, cost, and duration of development, which is Phase II.

The goal of Phase I is to learn enough about the system’s complexity to make an accurate estimate for Phase II. For example, how many different user types do we need to accommodate? What research methods are appropriate? How long will research activities take? What amount of custom code is required? Think of it like an outside-in discovery approach. We can define the system boundaries without knowing the inside details.

This phased approach lets us strike the right balance between flexible and concrete.

Just embrace the known unknowns

To conclude, comfort with ambiguity is key to innovation, but finding that comfort is easier said than done. To encourage our clients to give us space for innovative thinking, we involve them in the process, emphasize process over product, and structure SOWs to be flexible.

We know we’ll face certain unknowns at the beginning of every project; by doing the work, we eventually learn what we need to turn those unknowns into knowns.

The best advice I can give to clients who need more reassurance is to ask questions. The more familiar you become with the design strategy process, the easier it’ll be to trust it.