What designers do when designing is done
This is an abbreviated version of a talk I gave at SF Design week 2021. What’s the responsibility of a product designer once figma/sketch is closed.
What are we doing
What do designers do once designing is done? Once Figma or sketch is closed, a handoff to engineers is complete, what does a designer's workflow look like? At Earnest, our design process is optimized around this post-design workflow and yet the traditional process is not. The product design process has seen different iterations but the baseline has stayed the same throughout the years. Empathize, define, ideate, prototype, and test - the Ideo method. We’ve all seen some variation of this. As an industry, we’ve remixed this many times over.
We even have quirky drawings to map the muddiness of the design process within the product development process. As an industry, we’ve romanticized the craft of design and the design process but seldom do we talk about that space between design and development; the straight-line that leads from design to delivery. Traditionally after the handoff, we think of design as complete, this is a trope of young designers and unfortunately stakeholders.
As a younger designer once handoff was complete, I washed my hands, closed Sketch, and said my work here is done.
The current process is just that, waterfall, design, and complete. In the typical product development process, Design works continuously toward the sprint goal ahead of engineering. There's a period of context delivery, handoff, meetings about sizing, priority, releases phases, tech decisions. After all these conversations tickets are created, prioritized, developed, and eventually shipped and delivered. This can be a long time. This is what I like to refer to as the lag, this period of proverbial downtime for design.
The lag
One thing that happens in the lag is scope chop. A designer is given a problem, research is conducted, requirements set, usability tests were conducted and a solution arrived upon. A design gets handed off and then boom!
Some product owner, product manager, engineering manager someone with more juice, experience, higher up the food chain steps in and says we can't afford to ship this sprint, we have competing priorities, or this would be too expensive to do right now and Scope gets chopped.
Features, code, animations and design that were to be included in v1 are now out of scope, or too expensive, or can’t be prioritized, and are pushed for v2. This leads us to the second scenario the Elusive v2. More often than not we never loop back around for v2. What remains in production is what was descoped for v1. V2 just disappears and fades into the background like some magical memory that’s spoken of fondly that most of us wish we could experience but never will, like Woodstock.
And for then for the most egregious scenario, this has happened to all designers at least once, most likely early in your career. This is the scenario where a designer makes something in sketch or Figma, its spec-ed out, clear instructions, guidelines, animations, and what shows up in production is nothing like the original designs, aesthetic, functionality, alignment, or spacing. We’ve all experienced this before, unfortunately.
That is the old lag. Those are all the things that are currently happening to designers at companies all over the world and that some of you might have experienced. That's the traditional design process.
The new lag
Our process at Earnest treats every designer as a growth designer providing steps and processes to not only ensure those four scenarios don’t occur but to ensure designers are using the proverbial downtime to increase our ability to ship. There are 3 s principles that contribute to this new lag.
Iterate in small loops
The first of these practices: iterate in small loops. As designers, a major part of what we do is enabling our teams to learn faster. The more research, prototyping, surveying, and testing we do the quicker we can help the team make meaningful product decisions. Shipping smaller chunks allow the team to increase the number of feedback cycles. We all can attest design is not linear it's a loop and the Faster we loop the more we learn. The quicker we can do research, arrive at a solution set, and prototype ideas the more learnings we can bring back to our teams to make sound product decisions.
What assumptions can we afford to validate now vs what can we afford to validate later?
Assumption Affordance
As designers before we start that loop…..before we get into prototyping and testing. It's important we ask ourselves about assumption affordance. What assumptions can we afford to validate now vs what can we afford to validate later? The burden of prioritizing these assumptions should not be the sole responsibility of the product owner or manager. As designers, we have a unique perspective of what the future of the product might look like and what the team will need to learn in order to get there. We are uniquely positioned to help answer this question.
At Earnest to prioritize we use a rice sheet. Rice stands for Reach.Impact.Confidence.Effort. Our team uses a rice format to prioritize experiments based on feasibility and urgency. ….What can give us the greatest learning with the least amount of effort. In order to have the most accurate sizing, we have to be honest about unbundling and not packaging features together.
Although these things are already on the roadmap, with designers being in the room to help prioritize, we can reduce the risk of scope chop or the elusive v2.
By being a partner in the process we can ensure teams have alignment on which strategy will provide the greatest value and which is the highest priority. With this method in place going into the delivery state there's no guesswork or feelings that requirements will change. Prioritizing helps us define what are our product themes so we can agree on how to iterate in small loops.
Learn in the lag
The second practice is learning in the lag. Using the proverbial downtime in the process to continue learning and iterating on strategy and features even though handoff has occurred.
Now, there are two types of learning; learning for the immediate, this happens at the begging of the design process during the discovery phase. Then there's learning to inform broader work strategy and insights.
What tools do we have that can we do to help us continuously learn, evaluate, and revise our work and the strategies we’re building on? Can we collect additional information from onsite polls, can we send out prelaunch surveys, and compare them with feedback post-launch?
What about people?… how do we use people on our team to provide and improve product strategy.
Stewardship
The third and final pillar is stewardship. Even when designs are completed and were done testing there are still ways to deliver value for our not just our teammates but cross-functionally as well.
How do we help other departments tell the story? As designers, we work hand in hand with the PMs and engineers, from product discovery, solution-ing, to shipping. During the tale end of that process, design can have a tendency to stay within that product bubble. Once the design is complete the context of the release still needs to be socialized to other departments. In the Earnest product design process this step is called publish and support.
In the earnest product design process this step is called publish and support.
Support extends far beyond our immediate team.
Designs may be complete but Sales still has to sell the product/feature. Marketing still has to market it. Traditionally this is a role for the PM or Product owner.
But Rethinking the shipping process…. this is an opportunity for design to not only share context about the product but ensure context aligns with brand narrative and product strategy. Whether design is driving or not we’re still helping paint the picture of what the future should be.
This is an opportunity to create partnerships. How can you enable your team and the broader organization to do great work and ship great products. What expertise do you have as a designer that can be leveraged?
Thinking through different teams. Who has been left out of the process? Who wasn’t in the room to help make product decisions but will be impacted by a product change.
For example for teams like marketing……Is email marketing aware of the feature release, are there clear guidelines on voice and tone is customer support on alert for the launch, is the social media team equipped with the best assets. What if any of this information can be templatized for future use by other teams, who will need access to this documentation?
Stewardship is not just about cross-functional teams but internally too. How can we work more efficiently together? This is where to launch retros come in. Now, this is after the lag…. but..still important.
This gives us an opportunity to reflect on how things, went, double down on the things that went well and make changes to work more efficiently for the next sprint, the next feature launch? Can we change how we prioritize, adjust for gaps in design fidelity, combat things that happened in the lag?
I know what you’re thinking, Jason this is why we have PMs, product owners they’re entire roles dedicated to everything you mentioned The point here is not to do the role of other folks but become better collaborators in the work that's already being done. These processes that I mention during the lag period is not purely a solo effort. These require intense collaboration and should have shared ownership amongst a team. Collaboration is a vital part to ensuring the lag is efficient and effective.
Tactical Guide
In nothing else stuck hers a tactical guide in summation to help you and your team navigate the lag better.
- Iterate in small loops. Agree on what is the true lever, what is the primary metric we’re trying to move as a team.
- Is this metric unbundled from other complex ideas?
- Use experimentation to ship smaller and increase the team's feedback cycles. The faster you learn, the faster you iterate.
Iterate in small loops.
Iterate in small loops. Agree on what is the true lever, what is the primary metric we’re trying to move as a team. Is this metric unbundled from other complex ideas? Use experimentation to ship smaller and increase the team's feedback cycles. The faster you learn, the faster you iterate.
Learn in the lag.
Design will always come before development. The gap between the two is an opportunity for us as designers to continue learning. We can use this time to validate our assumptions, learn more about our audience and users, and test new hypotheses.
Lastly, Be a steward context.
Bring other teams along. Product development is not just a team effort, it's a group effort. Cross-functional teams are all stakeholders in the shipping process. Make sure you’re truly shipping together. Just because someone didn’t write code doesn’t mean they’re not part of the shipping process.
Thanks for reading. This is an abbreviated version of my 2021 SF Design Week Talk.
