Fast not furious UX design
Not sure about you, but in UX Design, I’ve experienced two prevailing philosophies. One is that “good design” is strategic, slow, & research driven and the other is that good design” (read: business-minded) is exploratory, fast, & test driven.
Either is valid but it can be frustrating for designers when a business expects both modes of work simultaneously. The ol’ “Ship faster but make it awesome” mandate from an executive team.
It’s frustrating because if the org is set up for a certain shipping speed, the only way to ship faster is to cut corners on quality. Shipping shit feels bad for designers, and it makes us disconnect from our work. But the mandate remains.
So the question is how do we move fast without breaking all the things?
I had this on my mind lately and wrote out some principles to help me shrink the distance between thinking and doing. LMK if they resonate with your or if you absolutely hate them.
Don’t get stuck in discovery
In a growth setting, we learn as we go, and discovery happens at different stages of the test and learn lifecycle. Reframe discovery as a tool instead of a phase. Ask yourself, what do I need to know in order to move forward? Then find the most direct and effective way to gain clarity. That might be user interviews, or a test, or that might just be a POV and clear hypothesis.
ABL = Always be learning
Most of us are in ever-changing industries & need to evolve the product experience. Tests, experiments, and fast-follow iterations allow us to practice being user-centered because it empowers us to truly understand and respond to user needs. Lean into design as an exploration: develop a hypothesis, design, test, learn, and iterate. It’s not about shipping a perfect solution; it’s about shipping the next step forward.
Get comfortable making decisions
We can’t move fast when we swirl. You got hired for a reason. Default to feeling empowered to make strong calls based on your expertise. It’s OK to take informed risk, and it’s also OK to fail, learn, and improve. An informed risk means that you are making the best decision you can with the constraints and context at hand. Take initiative and be confident in the moment — when new information comes to light, you make new decisions. The important thing is to move forward.
Feedback is for moving forward
Seek feedback that enables you to make decisions. Be explicit and ask for the feedback you need in order to move to the next step. For example, do you need to validate a decision, need to QA work, or check strategy? Your specificity allows for more impactful feedback. Treat opinions and feedback differently. Ask reviewers to use a feedback rubric in your reviews: SS — strong suggestion, OPO — one person opinion or M — mandate. (Michael Metts introduced me to that rubric)
Prioritize actions over assets
Frameworks help us be strategic & are key to strategic design. But our frameworks are tools for an output, not the output itself. Think of the framework as a map. It should have the minimum direction needed to get oriented & start driving. Somedays that’s a napkin sketch for a quick trip and sometimes it’s a full-itinerary for a road-trip. Size the framework effort based on the decisions that need to be made. Aim to be as light-weight, and as fast in your frameworks, presentations, and strategic artifacts as possible — we should be getting feedback on the action not the assets.
Give clarity on your role in the project
Develop & communicate clear definitions of the roles that we have in our product teams. Everyone has feedback, but who is making the final call? Who is the design lead? The “who decides what” should be clear for all key decisions. Stakeholders make suggestions, core members make decisions — ensure that everyone knows how they’ll contribute. What level of partnership makes sense for you and for the project goals?
Don’t swirl on scope
Makes sure you start each project with foundational information including:
* What’s the main people problem?
* What’s known and what needs discovery? (This helps scope meaningful Discovery work)
* What are we NOT solving for?
* What is our success metric?
* Is this exploratory work we can ship with a low/medium-confidence in order to learn and iterate or is this foundational work that needs high-confidence before shipping? What is our risk to confidence level?
That’s my thought dump on designing for Velocity with a capital V. Do any of these principles resonate with you? What would you add? What’s your favorite kind of sandwich? Mine is a turkey club. Bye!
This post was originally a very active Twitter thread
Thank you to the XD team at Expedia Group for providing feedback and inspiring me to write these down. Especially Rachel Kobetz, Doug Powell, Aaron Burgess, Michael Metts, Scott Noblit, Heather Sheraden, and Jared Meyer.
