Project Estimation, Part 3: Estimating Services Within a Design-Thinking Model

A Design-Thinking Model

For the benefit of my prospects and clients, I rely primarily on two diagrams when explaining design thinking to stakeholders:

1. The UK Design Council’s Double-Diamond diagram, which is shown in Figure 2.
2. Charles Owens, Vijay Kumar, and Steve Sato’s version of the four-square model, which they developed at ID-IIT (Institute of Design, at the Illinois Institute of Technology) and is shown in Figure 3.

To reduce confusion among stakeholders when presenting both of these models to them, I have modified the labels for both models so they map to one another. When you’re presenting either of these models to stakeholders, emphasize the following points:

• Design thinking shifts between divergent and convergent thinking. Use the Double-Diamond diagram to emphasize this point.
• In divergent phases, using the Double-Diamond diagram, show where UX services are likely to cause downstream scope change—either increasing or reducing scope—due to the expansion of possibilities inherent in divergent thinking.
• Use the four-square model to show the work moving through a cycle—in an ideal way. Positioning each service element in its respective quadrant is helpful in communicating dependencies among services. Also use the four-square model to show how divergent services would likely impact downstream, convergent services.
• Perhaps most important, presenting service elements in the context of a design-thinking model helps stakeholders understand the risks that are inherent in leaving out services that are fundamental to a successful outcome.

The four phases of the design-thinking model are: Discover, Define, Design, and Deliver. I’ll describe each of these in subsequent sections.

Discover

I prefer the word discovery over research. Many stakeholders have an allergic reaction to the word research. Discuss discovery within the context of supporting downstream activities. Specifically, when you’re discussing the types of service elements you intend to undertake within the Discover phase, link them directly to elements in other quadrants. By explicitly making these connections, you can focus the conversation on overall quality rather than costs or levels of effort. I like to say, “As a designer, I’m pretty good at making things up. But with the data that comes from discovery, I can make stuff up that matters.”

The Discover phase has the greatest impact on downstream scope. Make this clear to both prospects and stakeholders. For some projects, the number of unknowns may be so large that any estimates for work beyond the Discover phase would be wild guesses. However, except in very rare cases, I provide an estimate of all relevant services—even if my accuracy is little better than a guess. Even though my estimates may be wildly wrong, providing an estimate that is wrong is still better than providing no estimate at all, because it helps stakeholders understand the value of doing discovery in service of downstream outcomes.

When working as a subcontractor to other agencies, I’ve seen proposals in which discovery activities were completely separate from the work in other phases. But severing Discover from the other parts of the model devalues your overall work. A Discover phase is rarely useful alone. Its true power comes in driving insights and informing design and delivery. Further, separating discovery work makes it easier for the client to cherry-pick services from different providers. This is rarely a practice that leads to good outcomes. If stakeholders are simply considering bottom-line costs, they may think this is the best way to lower costs. However, they would likely be disappointed by the overall outcome, which would suffer from a lack of coordination.

Of course, some clients might hire us simply to do discovery work because they have the resources to cover the other parts of the UX process. But, even in those cases, it would be a mistake to ignore downstream service elements. Clients would still likely need us to participate in their process, even if only to a limited degree, to help them fully leverage the insights from our discovery work.

In my estimating tool, Discover has the most service elements, but for any given engagement, only a few of them may be necessary.

Define

When I was first introduced to Owens, Kumar, and Sato’s four-square model, I was struck by a comment Sato made: “It’s possible to satisfy customers by moving directly from Discover to Deliver, but the only way to delight them is to move through all four quadrants,” as Figures 4 and 5 illustrate.

The upper quadrants in the four-square model are often foreign territory for stakeholders. They involve synthetic thinking, abductive reasoning, and other skills that Finance, Engineering, and other data-driven practices do not necessarily require.

However, Define is the phase in which you can tease meaning out of the data you’ve collected during Discover. The service elements in this quadrant can help you counter the specious argument stakeholders often make against pursuing user-centered research: “You can’t figure out what users want by asking them! They don’t know.” Of course, that statement is absolutely true! But it shows a complete misunderstanding of what user research really involves. If you collect data through a bona fide discovery process, but fail to find meaning in that data, it’s hard to imagine you’ll build anything that truly addresses users’ needs.

Your added value to your clients is in the upper two quadrants. Your stakeholders need to understand the value of that work and how it fits into a project’s overall effort. I’ve found that stakeholders are more willing to discuss services in the Define and the Design quadrants once I’ve shown them how they build on the Discover services to drive their desired outcomes.

Design

Design includes a wide variety of service elements—from conceptual design to participatory design and, of course, presumptive design. But it’s equally important to include the service elements in this quadrant that we call thinking tools.  These are services that don’t necessarily result in a specific deliverable such as a journey map, but instead involve workshopping, collaboration sessions, and the like.

Here is an example of how the design-thinking framework enables you to quantize your work: You could offer a visioning workshop, let’s say, as a service element that is firmly in the Design quadrant and separate from any of the deliverables that are necessary to formally document the learnings from that workshop. Formal documentation belongs in the Deliver quadrant, so you could include it once you’ve traversed that section of the tool. But there may be excellent reasons not to provide these services. For example, perhaps the client has an in-house team who would do that work.

By situating the thinking tools and process activities of design in the Design quadrant and moving the separate deliverables of design work into the Deliver quadrant, you can help your stakeholders understand the value of design while remaining competitive.

Deliver

A few years ago, when I was working within manufacturing organizations, I found it shocking that the UX team wasn’t expected to contribute to work that occurred in the Deliver quadrant. Those companies saw User Experience primarily as a research group and left it to software teams to interpret and execute on the results. In contrast, in software-development companies—even those that don’t use agile approaches—most software engineers understand the value of having UX designers close at hand during development. Today, it is rare for our proposals not to include a significant amount of effort in the Deliver quadrant.

As I suggested earlier, I reserve the Deliver quadrant for the creation of design assets that support feature development. The services of this quadrant are often the most time consuming and costly because they require significant investment in coordination, iteration, and stakeholder management. Here again, using a design-thinking framework can assist you in selling a project. When a stakeholder expresses concern about the cost of delivering a design, you can show how you’ve actually reduced the cost through the services you provided during the earlier quadrants.

Of course, your stakeholders might think that Deliver is all about coding, so they might think you’re offering coding services. While you might be happy to offer front-end coding, it’s more likely that your clients have teams who are responsible for that. However, what they don’t have—and absolutely need to ensure they achieve the quality they’re expecting if they run into a snag—are UX insights. How many excellent design solutions have never been implemented properly because the reality of coding required a fundamental change to the original design? The service elements we offer in the Deliver phase support our maintaining the original intent of the experience, albeit with the expectation that the design will change.

Conclusion

Ultimately, you are trying to sell your stakeholders on the best mixture of services to meet or exceed their desired outcomes. Further, it’s necessary to differentiate your UX services from those of the competition. Design-thinking models are all the rage, so simply presenting your model to your stakeholders might not be sufficient to differentiate your services. But this approach isn’t just about using a design-thinking model to differentiate your services. Nor is it about selling design thinking as a service—although that certainly can be a remunerative service offering.

By establishing a design-thinking model to use with your stakeholders, you can accomplish two or, perhaps, three outcomes, as follows:

1. You can make it clear that you have a logical, replicable approach to delivering value.
2. You can set the stage for crafting a services estimate that easily and transparently adjusts to scope changes.
3. Possibly, you can establish a shared understanding with your stakeholders about your UX process. If you’re working on B2B projects, it’s likely that those teams are also using a design-thinking model. Comparing your models up front improves your chances of working more effectively together.

These outcomes are fundamental to the success of estimating and reconciling your services, which protects your value proposition and lets your stakeholders maintain control over their costs.