Beyond Discovery: Designing a More Valuable Phase One

Find out why you are right to be nervous about investing in a discovery and what you should look for in a phase one with any agency to ensure success and a great return on your investment.

If you’ve ever hired an agency to redesign, re-platform or otherwise do a bunch of work on your organization’s website, you’ve likely had to consider whether to pay for an initial phase of work some agencies refer to as “Discovery.” What follows are some reasons why you were right to be nervous about investing in something called discovery, but more importantly, what you should look for in a phase one with any agency to ensure that you lay the foundations for success and get a great return on your investment.

What is "Discovery" and where did it come from?

As far as I can tell, the use of the word “discovery” within professional services finds its origin in the practice of law. In legal practice,

[discovery] is the formal process of exchanging information between the parties about the witnesses and evidence they’ll present at trial. —the American Bar Association

I know what you’re thinking. Web designers and developers probably began using this term in the hopes of charging rates like attorneys. While there are definite corollaries between legal discoveries and the kinds of things that need to happen in any large digital project (e.g. the exchange of information to get everyone on the same page), it’s worth noting that our field is borrowing a term that describes a process for creating a fair fight. That isn't exactly the way I like to think about my client projects.

Also, the word discovery, based on its origins, alludes to simply an exchange of information, but not really the production of anything. It’s about finding things out so that you can then begin charting a course. It’s about input, not output.

Don’t get me wrong, discovery activities in and of themselves are valuable and necessary for most projects. The larger the undertaking, the more valuable they become. Discovery activities include things like:

  • The sharing and review of existing guiding documentation (e.g. style guides, personas, wikis, analytics)
  • Requirements gathering
  • Technical infrastructure review and analysis
  • The review of roles and responsibilities within a stakeholder group
  • The review and analysis of project repositories and assets
  • Inventories and audits of existing content, assets, resources, design patterns, etc.

These are all important things that you should want the vendor you’re working with to facilitate, but I’m guessing your team and your project sponsors may feel nervous, even disappointed if this is all they’re being promised in phase one.

Why agencies propose "discovery" phases and what's missing

If you’ve gotten a proposal that defines a discovery phase, in all likelihood, it provided a price for this initial phase that’s clear, but for the rest of your project is less clear. I know this because I’ve helped write many of these proposals. Often one of the “deliverables” of a discovery phase will be some sort of project plan that outlines a more narrowed cost estimate for the entire project. Prior to the discovery phase, the proposal may provide what’s referred to in the industry as a SWAG, or a ballpark range for the entire project to help you assess whether the vendor is at least within the ballpark of the budget you’re working with.

This is very typical for larger scale digital projects. If you’ve ever received a proposal like this, you may have been disappointed but not surprised to see that the proposal did not include an exact, fixed price for the entire project. It’s more important to feel confident that the vendor you’re choosing can be trusted to deliver something that’s successful within your budget. Ironically, at least at Lullabot, what we’re also looking for as we create project proposals is to feel confident that we can deliver success within your budget. However, if you’ve never worked with us and we’ve never worked with you, a mutual leap of faith is required.

Many agencies try to solve for the discomfort caused by discovery phase proposals by making the discovery phase as small and cheap as possible—the bare minimum needed to do just enough to feel somewhat confident in an estimate. Some even offer the discovery phase for free if the project itself is large enough to warrant the risk. I’m guessing if you’ve considered a proposal like this that you may have appreciated the cost consideration, but if the discovery phase did not appear to create anything particularly valuable for you and your team, you were probably still reluctant to invest the time in it. I’ve found that most of the clients we work with are just as busy as we are. If you’re hiring an agency right now to help you redesign or re-platform a large site, you likely don’t want your team to invest a bunch of time and energy in a discovery process, no matter how cheap, with a vendor you may not wind up working with, only to find yourself back reviewing proposals like this again. From day one, you want to find a partner you can trust to see you through to a successful launch.

So what’s the solution? If the lack of an exact estimate isn’t the biggest problem to solve, and making discovery phases smaller and cheaper also misses the needs and concerns prospective clients have, then what should we propose in these scenarios?

Moving beyond discovery and into design

A couple of years ago I was working with a prospective client to iron out an initial phase one engagement. They had a corporate intranet they were embarrassed by. Their organization was growing fast and needed to continue attracting top talent. Their existing intranet was terrible for onboarding new employees. It also looked like a historical artifact rather than an intranet for one of the world’s most innovative tech companies. After about three or four rounds of proposal revisions in which they kept saying this was not quite what they were looking for, I had the brilliant idea to just ask them “What are the things you need to have to get your team and the project sponsors excited and confident in the project by the end of phase one?”

What I discovered was that, as an organization, they understood that they needed a better understanding of the problems to be solved, and they understood that would require some research work, but our phase one proposal was essentially just research work. What was really valuable for their team was not just understanding all the problems more clearly, but rather seeing a vision for how to solve those problems. We did not need to simply understand things; we needed to make things based on that understanding. That would get their team excited and give them visual things to show their CEO and project sponsors who ultimately needed to get behind the investment in the project. That would even help them assess the value of the project and hence their budget. We were not certain exactly what we’d be designing and building, and therefore we did not feel confident providing a fixed estimate for the entire project. They did not know exactly what they needed, and therefore had no way to assess their budget based on value.

This is one of those things that seems so obvious in hindsight. As designers, it’s easy to know the amazing insights and game-changing ideas that can come out of initial research and forget that, while that’s all great and true, it’s the actual designs that solve the problems (even the problems we just feel but don’t clearly understand) that get people excited. As designers, we get excited about these insights because they’re the eureka moments that lead to the designs our clients rave about. Our clients want those designs that they’ll rave about.

The good news in the situation I just described was that the client was not saying they needed us to do the whole project as phase one. Nor were they saying they saw no value in the research and discovery-oriented activities we needed to do at the outset. They realized that the project was large enough that we couldn’t really describe and estimate it accurately without starting somewhere.

What we did was to simply end phase one at the point where we had produced what they were all eager to see; the initial designs for what their intranet should be like. We went from proposing a phase one that was just user research and discovery activities to a phase one that also included workshopping that produced wireframes and initial visual design ideas for a few key page types. Our early research and workshopping helped establish what page types were actually most important to success (e.g. Their employee dashboard at login and a couple other highly used content types and tools). Phase one got bigger by one or two weeks but produced things that were really valuable for our client.

Since that project, we’ve taken this approach to designing engagements with every new client. When a project warrants a phase one, our proposal process tries to establish the earliest things that are hugely valuable to the client team (usually via collaboration with that team). It’s not always the same things, but most phase one engagements seem to include the following kinds of things now:

  • Discovery activities (see above)
  • Lightweight research (user-research: both internal and external, market research, etc.)
  • Design workshopping to produce a plan in the form of models, diagrams, wireframes, and Zoom Mocks (see below)

Design workshopping: producing value quickly

To achieve great things, two things are needed: a plan, and not quite enough time. — Leonard Bernstein

We try to keep phase one as brief as possible, but ensure that by the end we've produced the initial designs for what we’re planning to create together. One of the huge benefits of including some actual design work in an intentionally-brief phase one is that the time constraint can provide amazing focus and clarity. It will force your team to quickly zero in on the things that are most important to your site’s users and your business.

While our initial research and discovery activities provide hugely valuable insights, they also typically raise questions. Decisions (or the lack of them) are what most often slow down design projects. There are teams of people involved, each with their own areas of focus and concerns. While user research and testing can certainly help guide decisions, even with these tools there are often several directions a given product or interface can go in. If you hire a professional design team, you may be thinking they will simply answer all these questions for you, but that’s not typically how it works. We’ve found that one of the keys to a successful project is the ability to arrive quickly at the early, foundational decisions together. We achieve this through design workshopping.

The concept of design workshopping is not something we invented. Our team has been doing this for years, and we’ve refined a lot over the years by learning from others. Kevin Hoffman has shared a lot over the years, and the book GameStorming has also been helpful. Recently Google Ventures’ book Sprint seems to articulate a slightly more formal, start-up focused version of the kinds of things we’ve been doing as well.

At its heart, design workshopping is about getting all the various roles and perspectives together in one place for collaborative exercises aimed at making initial design decisions together. Though we’re a fully distributed team at Lullabot, we almost always do these design workshops in-person. We fly a few of our people to wherever our client is and spend two to three days on-site together workshopping. We design the workshopping agenda together with our clients in the weeks leading up so that it fits with the various schedules of the client team we’re working with. Each day is divided up into workshopping sessions. The sessions are pretty brief (thirty minutes to an hour each), and no one stakeholder or team member needs to be in all of them (which would be impossible for most of our client teams). While no two projects are identical in their needs, some of the common things we focus on in our workshops include:

  • The existing pain points and problems to be solved as your team and users see them
  • Reframing those problems into prioritized goals and how to measure them
  • Your project and product’s constraints: political, technical, staff, resources and assets, brand, etc.
  • The competitive landscape for your product or brand
  • Your audience and its various segments, scenarios, needs, and priorities
  • Your content and its model, priorities, creation/editorial processes and governance
  • Your site and its IA, interface, patterns, page types, layouts and their respective priorities
  • Your brand and its characteristics, visual style, values and personality
  • The project process and your team's needs and values regarding phases, artifacts, deliverables, cadence, communication, etc.
  • Possible layouts and interface approaches to solve the problems and achieve the goals

Our workshops aren’t just conversations about these topics. We use a combination of methods and exercises to help elicit insights and drive decision making. Some of the more common methods we employ include:

  • Card sorts (often multi-axis)
  • Sticker voting (often in combination with a card sort)
  • Metaphor games
  • Gut checks
  • Design Studio sketching exercises

In one of Tom Wujec’s Ted Talks, he shares stories from an exercise he’s done with lots of business people where he has them draw how to make toast. At about five minutes into the talk he shares what he found when he began having groups do this exercise together, and he mentions a fascinating thing. When he had groups do the exercise together in complete silence they did it “much better and much more quickly!”

It never ceases to amaze me how you can get 5-10 people from an organization in a room and spend hours in conversation about challenges and goals for a project and still not arrive at a clear decision. However, when you apply the constraints of a “game” and give people set time limits, letting them work both individually and collaboratively, moving things physically in space to express things like importance, potential impact, level of effort required, etc., you can get that entire group to arrive at decisions together in less than an hour. Turning things from purely verbal, mental work into something physical and visual is hugely powerful!

Likewise, it can be incredibly difficult to articulate in words exactly what you don’t like about your existing site, or how you want your new site to feel. Instead, walking teams through metaphors with visuals and letting them describe why they think their sign-up process should feel like checking in at a W hotel rather than a Marriott, or why their non-profit organization’s brand is actually more like a Volvo than a Mercedes, can unlock so many more useful descriptive words and ideas to define what we need to create together.

While the decision making that happens in these workshops is often what blows away our clients initially, it’s the visual ideas that come out of our sketching exercises that put it all together. By the end of our workshops we have sketched wireframes for the key page or component types of a given site, and often our clients have helped produce these sketches. We’ve found that most project teams at the organizations we work with have at least some ideas for how to solve the problems on their site, and sketching is a great way to engage those ideas together.

Design Workshopping: Wireframe Sketches

Wireframe sketches from a design workshop

Typically, within a week after our workshopping, we’ve gathered together more refined versions of the things that document and visualize all the decisions we made together; things like goals and metrics, site maps and phase diagrams, IA and content models, wireframes and even Zoom Mocks that increase the visual fidelity showing style ideas that reflect the brand feel we’ve described together with metaphors. We have things we’re ready to test with real users and then iterate on to create a successful end product. What's more, we've continued to find these briefs can radically ease the onboarding of new team members later in a project or even to a product team after launch.

What have you found?

We’re always learning and refining, looking for better ways to design engagements so that they provide the greatest value to our clients and lead to successful outcomes. We’ve found that turning phase one from being just an exchange of information, discovery process into a process that produces ready-to-test designs to be a big win for our clients and us. We’d love to hear from you. If you’ve hired a design and development team to work on your project, we’d love to hear about what worked well and what you’d like to change on your next engagement. Drop us a line and share your thoughts. We’d greatly appreciate it!

Get in touch with us

Tell us about your project or drop us a line. We'd love to hear from you!