Congratulations, your product has survived long enough to need a redesign! This is something to be proud of, as is the fact that you’re also about to invest more in its future. But a redesign is a daunting task, with the successful launch day laying far over the horizon.

Bitcrowd has successfully lead many redesign projects, both for long-term clients whose products we’ve been building ourselves for years, and for new clients who find they don’t have the expertise or capacity to complete the task in-house. This post is an outline of how we work to bring as much certainty and security as possible to the process.

Background

At bitcrowd, we build and organise design systems and UI component libraries to create rock-solid, accessible user experiences. During this process it’s my role to collaborate with the designers creating design systems, to implement their design system and components in the frontend, and to facilitate communication between the stakeholders.

I’m writing from a product, design, user, and frontend perspective. This is an introduction to the processes we’ve developed here at bitcrowd; processes which we have found help clients successfully update their product design and improve their designer/developer workflow.

Why redesign?

Redesigning a product brings many advantages, providing benefits for your users by improving the product, and for your developers by clearing out technical debt:

• Visual improvements keep the product visually attractive and relevant to users.
• Revisit structural design choices that have been made over the product’s lifetime, with the benefit of hindsight and lessons learned.
• Holistically design features that were added separately over time. Your product now is different to the product you had when you first designed the feature.
• Technical debt: clean out old code, and update best practices.
• Use modern tech: make foundational use of new technologies, with new features and new possibilities.
• Reevaluate workflows: improve development speed by introducing new workflows that fit your product and team.

Not all redesigns touch all these aspects; limit the scope to help ensure a successful project. But a redesign is an opportunity to break with tradition in more than just the visual presentation of your product. Take that opportunity if you can.

A redesign is a story that resonates with us all — executive, product, design, and developer teams — and the most successful redesigns grasp this opportunity to improve the trajectory of the product long into the future.

This can be more than a one-off improvement that lands on the big redesign launch day.

Build a design system

To implement a redesign, you need new designs. More than that, those designs need to be communicated to developers in an actionable, auditable, and QA-able way. In low-level practical terms, this means building a UI library in your design software of choice, with structured design tokens and organised components.

That’s called a design system, with a component library built on top.

If a web app is ready for a redesign, chances are good that it was built before design systems were common outside corporation-sized companies. A design system is now table stakes, regardless of the size. No application is too small, though the smallest projects may get away with defining or enforcing the design system a little less strictly.

A well-built design system gives designers and developers a shared taxonomy and UI structure, avoiding many points of friction. They greatly speed the handover process between designers and developers, and the QA loop from developers to designers.

Designing on top of a solid design system and component library will create more consistent and reusable components, which are easier to implement and maintain, making your UI more understandable and useful for your users.

Analyse your starting point

To ascertain the viability and implications of new designs and features, analyse your existing codebase.

At this stage, at bitcrowd we ask for input from the client’s developers (frontend and backend), to get a clearer grasp on the current technical state. This helps us spot what could slow us down, and where refactoring may be needed before other work can continue.

Our developers also familiarise themselves with the codebase, poking into forgotten corners and searching out old tech and missing best practices. In recent years, we’ve been backed up by our own internally-developed LLM-based analysis tools, that help us flag potential problems in the codebase. We aren’t interested in being judgmental, this information informs our planning.

The developers here at bitcrowd are experienced and super talented. You can rely on them to give realistic advice during this process. When they see problems they work hard to find solutions, and prove themselves wrong. Hire us

Plan the transition

Implementing the redesign of any already-running product that’s bringing in income is a careful process. At no point should we disrupt users. One of the biggest questions we aim to answer as we plan with a client is:

“How will we transition from the old to the new?”

Plan out several approaches to rolling out new UI. Flexibility is required here, and for larger products you might not follow a single strategy across the entire app. Be prepared to differentiate parts of your app during the transition, rolling out in phases, knowing that they’ll all be back together as a whole by the end.

For smaller products, it can be possible to roll out a redesign to all parts of the project at the same time. But for most, it’s desirable to break up the rollout into smaller chunks. That could mean updating section by section, or updating every component throughout the entire product, one by one.

The goal here is to reduce risk and better track progress by creating smaller, more manageable packages of work. With this approach, it’s also easier respond to issues before they become problems.

Choosing a strategy is highly dependent on the product and the codebase. Is it more disruptive for users to see your design language change as they move from one page to another, or is the dissonance of new UI right next to the old on a single page worse?

Sometimes it’s possible to implement structural or UX changes and new features while using the old components, allowing changes to be rolled out carefully.

If your app has a public side and an admin section, that can provide a useful divide. The strategies can even be combined — to roll out a subset of components in a single area before moving on to the next.

Technical, design, and product requirements all have to inform this decision.

Choose your tools

Making a careful plan is essential to the project’s success. Find planning tools that fit your mindset, your teams, and the level of detail you need.

At bitcrowd, we make initial plans using visual mindmapping software, then break tasks up in a highly detailed and structured ticketing system. We find this keeps the early stages of planning dynamic and responsive, then adds more rigid task-tracking and estimation when it’s needed.

Stick to the plan

The larger and older the codebase, the more chances there are that you’ll find some edge case that you didn’t foresee. That’s fine. Though not foreseen, it should be expected. With the right roll-out strategy, you can minimise the impact of these inevitabilities.

With a design system where you had none before, and maybe an improved and updated tech stack, mean the chances are good that the solution you implement now will be better than in the codebase you started with.