Using design to explore your company's final frontier
Decisions are hard. Really hard. Especially when all of your coworkers are as passionate and opinionated about their ideas as you are about yours. To make matters worse, big decisions are expensive. A new feature can take weeks or months to build. A new process demands the painful unlearning of ingrained habits. On the other hand, talk is cheap. Endlessly discussing a new idea is so much easier (and more fun) than actually implementing it.
As a designer, driving change within your organization isn’t exactly straightforward. Buy-in is elusive: managers make 11th hour mandates, goal posts are moved, and the competitive landscape changes. Meanwhile you and your team are left flailing. This is, without a doubt, an issue most (if not all) designers have faced.
At FullStory, we have a framework we call a Prove-It to minimize flail, make big decisions, and ship. I won’t lie: Prove-Its are a grueling and testing experience at times. But setting a high bar always is. The outcome, though, is hard to argue with. It just works.
This post was adapted from a workshop given at Epicurrence on March 1, 2018, about Design Prove-Its. Use the shortcuts below to access the resources or skip to good stuff.
Can design help your company get unstuck?
As a designer, the onus is on you to take the first step toward envisioning the future. You are uniquely positioned to inhale all the ambiguity, contradicting ideas, impressions, research, and influences and create the first artifact: a wireframe, mockup, or a full-on interactive prototype. Only a designer can take what are only ideas exchanged between people and create something concrete to rally the company around. That’s our superpower.
But when sharing design ideas, there are common objections, comments, and arguments, all which get in the way of progress:
I like that idea but honestly, I dunno ... Is it really the most important thing we could be doing? I can think of 5 other things that feel more important to me. - Opinionated coworker
We were 3 weeks into building a new feature when a PM dropped in, saw the thing for the first time, and demanded we make some drastic changes. Now we’re back to the drawing board. - Anonymous designer
This is all wrong. Who approved this? This will no doubt going to create more support tickets than it eliminates. - Frustrated PM
I know I said we needed new onboarding, but our competitors just launched a chatbot and we lost a deal because of it. Maybe we’ll get to onboarding later. - Under pressure CEO
These quotes are contrived yet surely they feel familiar. Ambiguity and indecisiveness hurt and can be extraordinarily frustrating. Second-guessing and lack of buy-in make life as a designer hard and put a product’s long term success at risk.
However, through applying the Prove-It framework to design, the problems of second-guessing and buy-in are definitively solved, so that an entire team can commit to building something new with confidence.
Anatomy of a Design Prove-It
A Design Prove-It takes specific steps to eliminate second-guessing and get the buy-in of key stakeholders. Below you'll find a comprehensive guide to conducting your very own Design Prove-It including:
1. What is a Design Prove-It?
2. When do you do a Prove-It?
3. Who's involved?
4. Getting buy-in
5. The first artifact
6. The gauntlet
7. The deck — Skip here for the presentation template you need to conduct a Prove-It
8. Create your own Prove-It (Epicurrence workshop)
1. What is a Design Prove-It?
The purpose of a Prove-It meeting is to make a crisp decision about a single clear hypothesis. If approved, the Prove-It's hypothesis establishes the new Dogma under which the company will operate until such a time as the Dogma is changed.
Since the inception of Prove-Its, FullStorians have adapted the general Prove-It framework for more specific purposes. A Design Prove-It defines an idea, why it's valuable, its requirements, goals, scope, and of course, its design.
Other types of Prove-Its
We also do Prototype Prove-Its when a feature has been built to an extent that allows us to "feel it out" and discover any blindspots (we usually do). There are also Delivery Prove-Its, which happen when the implementation is done and the feature is ready to be shipped to customers. Ad Hoc Prove-Its allow us to change non-product processes and policies. Requisition Prove-Its allow us to justify and contextualize new hires.
2. When should I conduct a Design Prove-It?
Design Prove-Its define a path forward and occur right before the build phase of a typical product development cycle. The idea is to take in all the signal from customers, prospects, coworkers, and research to produce a clear, tangible, and implementable vision of the future.
Prove-Its inform and reform our Dogma, which serves as our bedrock assumptions about how to move forward. While the word "dogma" has some negative connotations, in this case, it's about eliminating second-guessing. As a company, it's important to be dogmatic about your hypotheses until new data is presented and a new idea is "proven" to nullify/mutate the old one.
(If you're curious to know more about Dogma, hop over to Dogma and the Suck Less Cycle.)
3. Who's involved in a Design Prove-It?
This may be the most difficult and expensive part of a Prove-It. Getting all the right, senior-level folks in a room for a few hours is hard and expensive yet crucial. Your C-level, Lead design, key stakeholders, etc. If you can get your idea over their bar, you'll get real buy-in, which is critical to creating with confidence.
So, who's involved?:
- Advocates: Who is actually making the case in favor of the hypothesis? Often it's one person, but it's even better when there are multiple advocates who can make a strong case.
- Attendees: With very few exceptions, Prove-Its are "everyone is invited" meetings.
- Approvers: Who needs to say "yes" to the hypothesis for it to be considered proved?
4. Getting buy-in
The real work of a Prove-It happens ahead of the actual meeting. Before even beginning the design process, clear validation from customers and coworkers around a given approach is helpful to ground any new idea. This is the research portion of any new design.
|Customer buy-in||Business/Sales buy-in||Engineer buy-in||Support buy-in|
|Usage data, user research, surveying, demand validation.||Deal-breakers, common objections, ROI analysis, competitive landscape.||Feasibility, Architecture audit, scoping.||Support cost audit, customer discovery, internal effort audit.|
The data points above help decide whether a new idea is feasible and worthwhile. When moving quickly, it's easy to skip this step or do it superficially. However, compromising on quality of buy-in only weakens your case. The more research, data, and context gained from customers and coworkers, the more likely your Prove-It will be approved.
5. The first artifact
As designers, this is where we shine. Until this moment, new ideas were merely intangible thoughts and words. In this shapeless state, we lack clarity around a new concept because we don't share a common vision for it.
The first artifact is the first mockup or prototype. Perhaps it starts as a simple whiteboard wireframe. Through feedback and iteration it becomes a concrete, ready-to-implement artifact. In this sense, designers are on the frontier of their company's future. Like astronauts in space, we must reach into the ambiguity and noise surrounding a new idea, and pluck out something concrete and actionable.
6. The gauntlet
You might be thinking, "There will be so many people in this meeting, so many opinions, so many objections." While that's true, it's also the point. True buy-in and commitment happens when everyone has a voice—a chance to be heard—and everyone takes ownership of the decision.
Attendees (especially approvers) need to be extremely tough, detail oriented, and set a high bar for what gets proven. All objections must be addressed. And sometimes, a follow-up Prove-It and additional work is needed to fully close the loop and win approval.
As designers, it's crucial to remain humble, positive, and action-oriented. The more iteration and feedback incorporated into the design, the more likely it'll get proven and receive long-term committment.
7. The Design Prove-It deck
As mentioned above, Prove-Its come down to a meeting. There's a presentation, and the deck acts a checklist. Each slide represents a mini delvierable or task that must be incorporated into a fully-fleshed out Design Prove-It.
Here are the components of the deck:
Hypothesis and goals
If successful, the hypothesis describes what will be considered the new dogma. Go for clarity and simplicity. Your hypothesis should be provable (or disprovable) and measurable.
Assumptions and data
Acknowledge that any prediction is imperfect (like all predictions), but justify your prediction with data and research. Think through what assumptions your hypothesis is founded on.
Pick a persona you’re targeting when writing your ideal flow. Imagine the perfect usage of your new feature. Describe its benefits to the customer or end user succinctly.
The first tweet is from the perspective of a user having just discovered the feature. Think about the words the user would use to describe the feature (not the ones you use internally).
The second is a marketing tweet coming from the company releasing the feature. The old 140 Twitter character limit forces the messaging to be distilled down to its essence while still speaking the customer’s language.
Risks and challenges
Brainstorm potential pitfalls with your strategy and approach. Ensure your design mitigates those risks while setting expectations with your team.
MVP vs. ideal scope
This step crucially forces designers to separate future vision from realistic, ready-to-implement next steps. Separating what to do first from what to work towards requires engineering buy-in and collaboration. The first artifact should be focused on the MVP design and perhaps have a mock or two laying out a longer term vision.
The first artifact
The hardest work happens here. Mockup or prototype of an interaction design, edge cases, customer journeys. Provide a vision forward but ensure the details are there too. Ensure the designs are ready for developer hand off.
Finally, the moment of truth: is your hypothesis proven or do you have to go back and do more work? If you're successful, you'll have created new Dogma through which your design team—and the company—can move forward. Congratulations!
Download the template (The content in the template slides relate to a fake scenario and fake idea).
8. Make your own Prove-It
Have a big idea you want to pitch to your coworkers? Identify with a lot of the problems outlined earlier in the post? Use the Prove-It framework to add rigor, structure, and context to your next big idea.
Earlier this month, I ran a workshop at Epicurrence in beautiful Yosemite National Park. We came up with big ideas using a fake scenario. Everyone broke up into groups and over the course of a 90 minutes, created their very own Prove-Its.
If you're interested in giving it a try, download the resources below:
At FullStory, we've used Design Prove-Its for everything from small UX changes to large-scale, longterm redesigns. In every case, design played a major role in clarifying the future, gaining buy-in, and helping the company commit to new approaches supported by contentious assumptions.
Next time you have an idea, don't just jump into Sketch, go into a hole, crank on UI, and show someone once it's "ready." Take the time to conxtextualize your idea, do the research, get the buy-in, speak the langauge of your colleagues, and package everything up into a concise, shareable form. Instead of meeting a strong headwind of opposition, objections, and hedging statements like, "This looks cool, but what are use cases?," you may find that an idea wrapped up in a Prove-It will get gain a lot more momentum, solicit constructive feedback, and ultimately - get shipped.
Try it out and let us know — did it work for you?