Is there ever a good time for a product redesign?
Tips to find space for product design work on a value-driven roadmap.
P.S. from the Product Stack is a newsletter from the Product Stack that aims to answer your product questions with actionable insights based on real-world experience.
--
A common frustration all product teams will surely come across in their career is trying to justify the prioritization of a roadmap project that doesn't have direct, revenue based ROI. Projects like tech debt and library upgrades often fall in this camp. As do design projects.
A ways back, we hosted a fireside chat webinar with product folks from Pivotal Tracker, Product Plan, and Jama Software -- all having experienced a product redesign in the past. We covered common roadblocks to watch out for, discussed how to pitch the ideas to upper management, and dug into some of the driving factors for a redesign in the first place. If you haven’t seen it, it’s worth a quick watch.
While we covered a lot in an hour, we also received nearly two hundred questions from our audience. Clearly this is a topic that needs some more exploring. So we wanted to dip into the mailbag and see if we can provide some more direct guidance.
A common chicken vs egg scenario surfaced via a question from Joel at Linux Academy. He asked…
How do you handle a redesign with new features that are being developed, but that will have to be revisited on redesign?”
It’s a great question tied to a valid concern: why do I want to create additional tech/design debt that I am going to have to fix later?
During any redesign project, you will always have to assess whether you are stopping all development to redesign what you have or whether you should somehow juggle both at once. Very rarely are you going to get approval to do the former, so how do you tackle the latter?
Simple: Think big, act small. Ok, not that simple...here’s what it means.
Thinking big means you need to have a full understanding of where a redesign is going to go -- you don’t want to design in a vacuum and hope it’s all going to fit together in the end.
Acting small means now that you have the vision, you need to find ways to influence design changes through small, incremental steps -- some of which may require two or more steps before getting to the final design.
It’s a process my team is currently in the middle of right now. Here’s how we are approaching it. In order to refine our thinking, we created two documents that capture the big picture while allowing delivery teams to look for quick win opportunities during larger roadmap initiatives.
We documented and shared design principles for everyone to rally behind
We documented an existing (and evolving) design system for developers to reference
With these documents, we can more readily tackle small problems and identify ways to get each one to align with that vision without creating additional design debt in the near-term future.
To prioritize these small problems, you’ll want to perform an audit of existing components and workflows across the application and rank them based on how well defined and solidified their design rules are -- in other words, can a developer look at this documentation and know how to implement it? We started with the building blocks of the application (buttons, forms, tables typography, colors) to build consistency for our teams.
Your goal is to empower developers to implement new features, or clean up old ones if they happen to be deeper in the code, with confidence (and less questions to the design team). This frees up the product design team to focus on some of the stickier parts of redesign.
Over time, these small actions will compound into an improved design and experience leading to a tipping point where most of the redesign is implemented and you don’t have significant design debt on your hands.
We’d love to hear your thoughts and experience with this. Feel free to join our Slack channel to continue the discussion.
Stay productive,
Kevin