Redesigning an app from the ground up

#beginners #javascript #webdev

I've been doing frontend for 7 years now and if you ask me what all my projects had in common, I would say all of them have undergone a redesign process at some stage.

When building UIs, you will most likely go through several iterations before you get the experience just right. At Neon, we’re currently redesigning our console for the second time. The first iteration focused on ensuring that the console was production-ready. Our goal now is to enhance the overall UI/UX.

This redesign process can be painful if done incorrectly, especially when multiple teams are involved. Features don’t ship as quickly and bugs start slipping into production. Fortunately, it doesn’t have to be this way. In this post, I’ll share my experience and what I do to ensure that the redesign process goes smoothly.

The tips I’ll share are framework agnostic and can be used in any front-end codebase.

Organize your code base

Even if no major redesign is happening soon, you should organize your codebase in a way that allows you to easily update a single element or the entire application.

Avoid code duplication

A good rule-of-thumb is to avoid code duplication. Duplicated code is harder to maintain, and makes it easy for bugs to slip into production.

For example, you might find a bug, fix it in one place, find out that it is present elsewhere, and re-apply the same fix. This duplicated effort decreases your efficiency and takes away from time that could’ve been spent on building new features.

If you find yourself duplicating markup or the same logic in your frontend, it’s possibly a good signal for you to consider abstracting the markup or logic into a reusable component. It also is a good idea to co-locate the component’s markup and styles rather than having all styles in one CSS file. Choose a methodology and stick to it. It doesn’t matter which style or convention you pick. What’s important is that you use it consistently across your entire codebase.

Another thing to consider is replacing hardcoded values for colors, gradients, shadows, font sizes, spacing, etc., with variables. You can use CSS variables, or a CSS preprocessor like SCSS to achieve this behavior. Doing this will significantly reduce the time it takes for you to fix bugs or evolve your UI, since you will only need to make changes in one place. It will also be easier for you to add support for theming (e.g., dark theme).

Abstract third-party UI components

Building components such as selects, calendars, date pickers, etc., is not straightforward. You will need to design the API for them, consider all edge cases, and ensure they are accessible.

This can be time-consuming and shifts your focus from shipping features, which is why many developers reach for third-party component libraries (e.g., MUI, Mantine, etc.)

It’s a good idea to build a wrapper when using these components, this way, you can swap out the underlying library without updating several instances of the same component. Building a wrapper also allows you to use only the features of the third-party component that you require rather than supporting the entire API. The following example shows how to create a wrapper for particular features of a third-party API:

import {
  Button as MuiButton,
  ButtonProps as MuiButtonProps
} from '@material-ui/core';

interface ButtonProps
  extends Omit<MuiButtonProps, 'onClick'> {}

// only the onClick prop will be passed
const Button = (props: ButtonProps) => {
  return (
    <MuiButton variant="contained" {...props}>
      {props.children}
    </MuiButton>
  );
};

Work with your team

There are usually many people involved in the redesign process, from designers and stakeholders to project managers and developers. That is why it is crucial for everyone involved to be aligned on the redesign plan and the goal of the redesign. Otherwise, there might be wasted efforts, delayed releases, or postponement of new feature development.

Define the scope and the release sequence

Which parts of the application will change? Can these changes be done in parallel while developing new features, or will they require your team’s full focus? Will you do one big release or several smaller ones?

Depending on the size and complexity of the project, you will have different answers for these questions. If you are working on a large project, you will most likely release your app’s redesign over several phases and introduce many small changes rather than few big ones. This approach avoids blocking the development of new features.

If one of the redesign’s goals is testing some hypotheses rather than developing the new design, it might be good enough to use a prototype built using a tool like Figma. This approach can save a lot of time and development effort. On the other hand, maybe while you’re implementing a mockup, you found a better way to achieve the redesign’s goal. In this case, it’s important to sync with the design team for feedback.

Test before you ship

It’s important to ask the following questions before shipping a major redesign:

Is it clear how to use existing features with the new design?
Are all the happy and unhappy paths covered?
Did we introduce any new terms, and how are we explaining them to users?

Having people who weren’t directly involved in the redesign review changes and test new features can help with catching bugs or peculiarities you may have missed.

Final thoughts

Once all the bugs are fixed, and everyone is happy with the new UI, deploy it to production and celebrate. Redesigning an app can be a challenging project. Following these principles will make your redesign process easier.