A Guide to Designing for React

Completing Udacity’s React, Redux and React Native Nanodegree has transformed my thought process about how I approach UI design. This post aims to leverage some of the React principles to produce more efficient and consistent designs, for React and beyond.

Thinking in React

Facebook has created a great article that outlines its component-based model. The article demonstrates how a UI mockup is broken down into its constituent components to identify how many and how often each component is used. I would highly recommend this article if you have never designed for React and want a straightforward overview of what your front-end devs expect.

You have probably already designed for React

A few years ago delivering a Photoshop PSD design mockup would be commonplace. Photoshop was the standard. A photo editing and manipulation software became the go-to for designing for the web. Hours of labelling and duplicating stacks of layers while remembering to periodically save before the system decided it was time for some spinning beach ball fun. You'd finally get through and deliver your PSD to your client or dev team, only to be told the colour of all of the buttons and the border radius needed to change. You'd drag yourself through hours of redesign to update every instance across your entire file.

Thankfully design has moved towards app and web-centric design software such as Sketch, Affinity Designer, Adobe XD and Figma to name a few. A significant difference is the ability to create master elements (also known as Symbols or Components) that you can reuse across your design. Each copy inherits the properties of the master copy, allowing you to control each instance of the element throughout your design file. This allows you to design your element once and use it anywhere, just like the component model used in React. Since I use Sketch, I will be using Symbols as my reference to master elements from now on.

Designing React Components with Sketch Symbols

Each piece of UI you create should be built using Symbols. Symbols should only perform one action, which is known as the single responsibility principle. When a symbol has only one job it can be reused in numerous places without the need for duplication or modification, which is a core of the DRY: Don't Repeat Yourself principle. In Sketch, Symbols can be nested, allowing you to build more complex UI mockups in much the same way a React developer builds components. Symbol overrides offer variability to the design, helping you to validate your composition against real-life content.

Taking the filterable product table example from the Thinking in React article, we can design this in Sketch with Symbols acting as our components. I have created a sketch file which you can download here. This file contains the various nested Symbols which almost perfectly mirror the component structure of the article. This allows me to rapidly iterate and isolate just the symbol I require to be developed. I can also validate modifications to any master Symbol changes, effectively highlighting potential bugs before they go to code.

Designing your mockups with React in mind allows you to spend less time repeating yourself; replicating the same elements over and over. Saving time is always appreciated, both by your executive team as well as the developers that will implement your design. You'll begin to create a bank of reusable and customisable elements which can start to become the basis for your Design System. Designs will be easier to communicate as they can be broken down and explained on a per-component basis. Since you are creating designs from various reusable Symbols, you can laser focus on the subtleties and gentle nuances, such as the animation or micro-interactions. Meanwhile, your developers can focus on meeting the building needs of the various components.