What is The Big Design Refactor?
Design starts with systematic thinking and then shifts to incremental changes. No matter where a project starts, at some point the design systems’ integrity will degrade to the point that you need to look at the whole thing fresh. Welcome to the Big Design Refactor. In the beginning, you had a beautiful, functional design system. And then you had to watch, helplessly, as it degraded under the weight of a thousand tiny changes. It’s maddening, and a big reason many designers are allergic to Agile methodologies.
What can you do? Understanding and accepting that this design-system degradation is an affordance of differently-sized design and development cycles is the first step towards making peace. Once you realize and accept this change, it’s much easier to deal with. Plan on it. Talk about it with your team. Designers need not work at developers tempo. Rather, they should strive to stay in-rhythm with development, working at their own pace, and making sure their beats and decision-points intersect with development at regular intervals.
As the designer, it’s your job to keep an eye on the health of the graphic system. Just as the developers incur and pay down their technical debt, you’ll manage your design debt. How? Mention that the graphic system is starting to break down. All the while, you’re still doing your work. Keep solving the tactical problems, keep delivering value. At some point, the balance shifts: you’re no longer plugging little leaks or engaging in preventative maintenance. The system is undermined; the cracks are starting to show. Now’s the time to have a talk with your team. You’re going to need a few weeks to work on this. You’re going to need the development team to find something design-light and backend-heavy to focus on for a week or two. Hold a design retro. Get their feedback, and their buy-in, and their good ideas. And now you’ll have a break from the tactical work of patching up design as features iterate. You’re a Pure Designer again, working in your idiom, experimenting and sketching and building a new design system.
How does the Big Design Refactor work?
When I’m in the midst of a Big Design Refactor, I’m spending most of my day in Adobe Creative Suite. I’m pulling the product team over ~4-7 times a week to bounce ideas off of them. I’m pinging the development team ~1-2 times a week to consult on the technical implications of where I’m going. By the end of the week or two, I’m usually delivering a set of user stories accompanied by mockups. It’ll often take an IPM or two to get through all of them, and it’s important that they get implemented soon. Nothing feels more like waste than a heavy investment in design, followed by unacted-upon stories that go stale. This will kill trust between the design and product teams (in both directions); it’s downright poisonous.
Now, while the new design is being built by developers, I’ll occasionally hop back into Adobe Creative Suite for assets or newly-discovered UX tweaks, but most of my time is spent pairing with developers. I’ll also keep a close eye on acceptance. Pixel-perfection is rarely necessary, but miss an important UX point now and the error will become enshrined as part of the system.
Once the Design Refactor has been assimilated into the app—and it’s rare that 100% goes in, but 80-90% is the norm—it’s Tactical Incremental Fun Time! I’ll spend most of this time pairing on stories, picking of styling stories to solo on, and working on design problems revealed by user testing. At this point it’s probably 66% development and 33% Adobe apps. The debt clock is starting to tick again, and once the pain is noticeable, I’ll start making noises: “we’re ok for right this second, but we’re going to need a design refactor in the next 3-5 weeks”.
Why are the Rhythms Different?
Design and development are activities that move at different speeds. Test-driven development and Agile project management allow developers to break work down into small stories and iterate on them. The unit of work for the “what” of the story is “what’s the smallest possible thing that delivers value to the user?” and the “how” of the story is “what’s the simplest possible thing that can work?”. These units of work tend to translate poorly to design, because effective graphic design is almost always a system. Changing arbitrary pieces tends to degrade the whole. Design adjustments that are close in size to development units-of-work can be made, but they inevitably undermine the graphic system, creating Design Debt. Debt is fine, if used responsibly, but it needs to be paid down at some point. (More on that another time.)
Developers work at a quick tempo. They use Agile’s small units of work to facilitate a supple workflow that responds gracefully to changing client needs.
The customer wants to re-prioritize a feature? No problem! Move it to the top of the backlog and we’ll get to it next.
Because they’re backed by tests, devs are free to move around the codebase and project, making changes where the customer likes, with the confidence that their test suite will protect them from breaking the app. Designers have no such safety net—which is one reason that developing meaningful automated testing for design is crucial to a mature Agile design practice.
The rhythm of design is slower. Design pulls together an information architecture, UX metaphors, visual styles, a typographic system, a color system. Visual rhythm, hierarchies, and scale combine into a whole graphic system—more than the sum of its parts. All these pieces interrelate, and changes cascade into other. While adjustments to individual design elements can happen quickly, feature-scale iteration doesn’t allow for changes to the system; those take more time.
TL;DR
Ideally, bring a cohesive graphic system to Inception. Accept that it will degrade over time. Make tactical adjustments to keep pace with agile development, and plan on overhauling the design system every quarter or so.
About the Author
