Imagine you’re responsible for providing services to a stakeholder—whether you’re working for an agency or within an inside group. To win the stakeholder’s business, your value proposition must make your services more attractive than those your competition provides. This is a pretty typical situation for those of us who are responsible for business development—whether external or in house.
In Part 2 of this series, I presented a tutorial for creating a spreadsheet that helps you transparently scope, estimate, and reconcile services in a way that puts your customers in control of the scope of effort. In doing so, I defined the five basic steps that are necessary to build this tool:
Identify the services you’ll provide.
Perform a time-and-motion study for delivering each of these services.
Quantize and assign a price to each of your deliverables.
Build a spreadsheet that includes each quantized element.
Refine the spreadsheet as necessary.
Hopefully, you’ve been able to follow along so far. Perhaps you were even able to build a spreadsheet for your own services.
You can apply this approach to the development of service elements as quantized parts of an overall service offering to any sort of service company. When I first developed this tool, my focus was on CAD (Computer-Aided Design) services, as Figure 1 shows, and I charged clients for each part I placed into a blueprint.
The example proposal in Figure 1 demonstrates how I applied my approach to estimating and reconciling piece-work services. In that CAD context, it was pretty easy to identify what the costs would be for each activity and each discrete piece of work. More importantly, my service business relied on a computer to do the actual counting of pieces. Not only did this meet my client’s requirement for an accurate, CAD-based count of furniture pieces, the thing we billed against was the very thing the client actually needed for their business. Quantizing the effort was a no-brainer—my fees tracked any changes in the size, complexity, or scope of the actual deliverable.
Expanding My Approach Beyond Piece-work
How applicable is this approach to the broader range of services a UX group is likely to offer? Is it really possible to charge on a unit basis for work that simply takes time to complete? Consider the classic problem of your needing to do discovery before you can figure out how much or what kind of design work is really necessary. How can an estimating system account for downstream work when that work might never be necessary? Even limiting this challenge to partnering with other firms in a B2B (Business-to-Business) context, how can an estimating system help your partners understand your pieces of the work when those pieces don’t relate directly to their work?
By taking a systematic approach to defining design services, I have been successful in expanding my system for estimating and scoping projects from piece-work to almost all of the UX-service elements I’ve needed to estimate—from user observations to game design; from persona creation to user-story writing.
To help explain to your stakeholders—whether prospects or clients—how your service elements work together, situate each element within a larger design framework. I use several different design-thinking frameworks in my practice. In the next section, I’ll review two of these frameworks to set the stage for their use as a means of systemizing design services. Then, in the next installment of this series, I’ll show you how to position each service element within a design-thinking framework that enables you to communicate clearly to your stakeholders how each element relates to others.
Positioning your UX-service elements within the larger framework of a design-thinking model is key because it lets stakeholders clearly see where you might need to adjust downstream work based on upstream outcomes. But there is another, equally important benefit of communicating your design framework to your stakeholders: they need to know that the work you do isn’t magic—that there is a rational way to describe it. Some of your stakeholders—especially those who have less experience with User Experience—might not have a firm grasp on the different types of services that UX professionals offer. In the past, when I’ve tried to describe the services I offer without first situating them within a design-thinking framework, I’ve often engendered confusion among my stakeholders, making the sales process more difficult.
However, let me be clear: While having a framework makes it is easier to describe your design process as rational, logical, or linear, the reality is that design work is messy. We cannot deceive ourselves into thinking that having a conceptual framework means our actual process is equally tidy. That’s not the point anyway. The key point is that we serve our stakeholders best when we start with the big picture—a design-thinking model—to provide context for the services we offer. With such a framework in place, you’ll be ready to discuss the different types of services you offer, how they apply to solving different problems, when they occur, and how they impact one another.
Establishing a design-thinking model and situating particular services within that model delivers several benefits, as follows:
Stakeholders better understand the dependencies among service elements.
Clients’ teams and our own can coordinate our efforts to work in parallel, collaborate together, or work independently, depending on their needs.
Stakeholders better understand how scope could change in some phases, but likely wouldn’t in others.
A Design-Thinking Model
For the benefit of my prospects and clients, I rely primarily on two diagrams when explaining design thinking to stakeholders:
The UK Design Council’s Double-Diamond diagram, which is shown in Figure 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.
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.
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 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.
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.
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:
You can make it clear that you have a logical, replicable approach to delivering value.
You can set the stage for crafting a services estimate that easily and transparently adjusts to scope changes.
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.
With over 30 years of experience in design management and design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions. At The Home Depot QuoteCenter, Leo leads a dynamic team of UX professionals in delivering engaging experiences for Home Depot associates. Previously, as Product Design Manager at Intel, he led UX teams on mission-critical programs. As Principal UX Architect for Tektronix’s Logic Analyzer product line, he filed several patents and spearheaded product vision and definition for the next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 20 years, he has served as Program Chair, Chair, Vice Chair, and Treasurer on the board for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland Chapter of SIGCHI. Read More