Breaking down large redesign projects
Breaking down large redesign projects
Hey all, Allan here:
I recently found this thread on Reddit asking for help on creating a process proposal after a large redesign. The ask is as follows:
I've been working with an established B2B SaaS client for the past 6 months, doing a UI/UX overhaul. We've done extensive user research, did some sprints, reworked a lot of flows, and used all that learning to design and develop a full design system from scratch.
Now they want me to stay and help them design every screen using the new design system. Their software is like a whole operating system for a niche industry and probably has around 50 flows and more than 300 pages. How should I approach this?
They're going to prioritize flows and screens and send me work orders in batches. But I was told to come up with a process proposal so that they can get approval from execs. Do you have any suggestions?
So you’ve done your research, gotten your approvals, the system is ready to go—now what? This is a practical question that I also faced a few years ago, when creating Teachable’s first design system.
A lot of my own navigation through this process was trial and error so I thought I’d share some of my learnings around creating an implementation process.
Prioritize and size first
A big key in going about this is getting feedback from Product and Engineering around the following: what flows/pages should be prioritized and what flows require the most engineering effort. Being present in these talks and ensuring everyone is aligned is key to dictating the right thing to tackle first while also keeping the work manageable. In this particular Reddit situation, the client probably shouldn’t be making the decision of what flows to fix first without input from this freelance designer as they may not be fully aware of the lift necessary to change certain flows.
Short-term vs. long-term
Next would be to establish guidelines around what changes immediately and changes later. For example: in addition to prioritizing certain flows to be redesigned, making sure that all stakeholders know that all new pages+flows should be built using the new design system.
Another thing to take into consideration is how users would interact with the new design system—there’s a need to ensure that important flows are thoroughly changed and measured against the previous design in order to be optimized not only from an analytics standpoint, but an experience one as well.
QA heavily involved in implementation stages
A final thing to consider would be to have QA and frontend devs heavily involved in the implementation process to make sure no hiccups occur. I’ve had success before using Storybook to ensure as close a reflection between frontend design & the design system as possible. Having a source of truth on the dev side also allows documentation of the major parts of the design system for later, negating the need for a designer to spell everything out when building out ancillary pages.
The goal is to make it so that it’s a manageable handoff and reduce the need to handhold as much as possible. Thoughts? Additions? Let me know what you think by emailing me at allan@keming.io and I’ll follow up in a future substack update!
Allan is a freelance product designer who works with startups and large tech orgs alike. Clients include: Floyd, Automattic, Wingspan and Pepper. Before that, was the first dedicated product design hire at NYC startup Teachable and led product & design for several years at AdmitSee, an edtech startup in San Francisco.