The design field is moving forward, and it’s moving really fast. Some months ago Sketch had changed a lot of things with the implementation of Symbols. This simple but powerful feature allowed us to start thinking about Design Systems instead of having just a bunch of screens to communicate our designs. The benefits of having a Design System are significant, most of them play around the idea of reducing the gap between Design and Front-End developing.
Now, Symbols are just the top of the iceberg. Engineers have been playing with reusable components for a long time, and that’s the reason why React has become huge in their community.
“Symbols are just the top of the iceberg of a new world of possibilities to make design with reusable components”.
React and Symbols follow the same principles of making a product more efficient by using components. Actually, Symbols are just a primitive way to structure a proper component-based system, although following that effort, React is a more powerful framework, but for obvious reasons, it is not related to the design work at all… until now.
The team at Airbnb has been working on tying up React and Sketch App, and the result is amazing. Even when the development of this relationship is still in a very early stage, the possibilities for a big change in the design-tech field are exciting.
I’m not a developer, but I like to code whenever I can. React has been something I’ve wanted to learn for a long time since I started to play with Rails the last year, and now, with this tool, I’m like a kid with an awesome new toy. After playing a little bit with it this week. Here are some bits of advice to build a real, dynamic and (I hope) a powerful Design System.
How to get started?
If you are a designer without experience in developing, the first thing you should know, in general, is to read the documentation. As I said before, none of this would be possible without the incredible efforts of Airbnb team, so I highly recommend to review the official GitHub repository here.
Besides, the information you can find there is important to understand how this works. This is not a plugin for Sketch. The idea is simple. With this tool, we use React to generate the design in Sketch. By doing that, Sketch turns into just a way to render what React has coded. I know what you’re wondering. Why is this necessary? We will get to that in a bit.
Let’s get started! First, we need to install it. The repository has the necessary instructions to download the examples they have there, but if you want to start a new project from scratch, here are the instructions:
After you’ve downloaded the repo on your computer, go to the examples folder and copy the content to another folder with the name of your project. I recommend using the Styleguide example, it has the basic structure based on what I’m working on.
Create a new sketch file and save it inside that folder. The name doesn’t matter (it’s going to be deleted anyway).
Go to your console and then go to the project’s directory. If you’re a beginner coder, you can use the Terminal or iTerm2, then run the following commands. In this case, I have a folder called “Code” where I have all my projects, the project I’m using for this example is called “loginProject,” so the commands to run will look like:
With all the Node dependencies installed. Open the file “styleguide.sketchplugin”. This file will install the necessary connections in Sketch to tie with your React code.
Open the Sketch file you’ve created at the beginning, then go to your plugins tab and select the new one that should appear there. By doing that, an option should appear to run it:
Although, you can also run the render from the console using the following command:
NOTE: If you still don’t have a code editor, Atom is a really good and nice option, it has a pretty decent UX.
All the work we are going to do will be performed in the “src” folder only. So go there and delete:
- All the files inside the components folder.
- If you’re using another example as a base, delete all the files except:
There are 2 files that are really important and you should know their function:
This file will contain all the reusable properties. Mainly Colors and Typography styles. For example, if in the future you would want to update a color, this is the place to do it (and it will be changed in all of your components!).
This file is the main connection with Sketch, so everything will be exported from here. To start from scratch go there and delete all the code.
And now… let’s make a pause.
Defining a workflow
Before we continue, we need to be sure what we want to do with this tool, how it is going to interact with Sketch and what will our workflow look like. Given that we face a lot of challenges like the fact that designing from the code is not fast enough to make great designs, this is my suggestion:
Think of React + Sketch project as a master, as the Source of Truth for the product you’re working on. Which means you’re not going to design there directly, but you’ll put there all the new things you have designed previously. If you’re familiarized with Git, think about this process like:
- A new requirement to design a new component or to make a change has been received, like an issue in GitHub.
- Use a new Sketch file, outside this master folder, to make a rough design of your solutions and to make the necessary iterations with your team. This would be like your branch.
- Once the iteration is finished and your design for the new implementation is done, it’s ready to be “merged” into master. So, now is the time to code all the necessary components, make the necessary changes in React to put your design there according to what you’ve designed in your branch. You can try to use all the components already coded and the colors and typography from your designSystem.js file or you can also create new ones.
- Now your Source of Truth has been updated and ready to receive new implementations.
This is a very important part, it’s what I call a coherent and a well thinking iteration flow. A key component of this proposed Design System.
Building a Design Structure
Now, let’s go back to our React + Sketch project. Through this post we are not going to build a big product, I just want to show some basic features and propose a structure, so let’s make a simple Sign Up and Login design.
For this small example, and for bigger projects where you can use this tool, this is the structure I suggest to manage your files:
The key here is to have a coherent way to manage your components. Even with Sketch Symbols, it may turn messy when you start adding more and more stuff, so the structure has to be made thinking of scalability. This is my suggestion to organize your components:
If you are working in a team with Front-end Developers, ask them for an advice. Would it be really helpful in order to be on the same page, will this reduce the gap between your work and the Developer’s work, or in other words, you as a designer will be speaking the same language, metaphorically speaking of course, because the code you’re going to write in React is more similar to React Native, so for web applications, the code will not be the same, but having the same components structure is an important step in a good direction.
Once you have your components structure already defined, now you have the necessary stuff to start with the fun part.
Let’s design with code!
Before we start, let’s take a Sharpie and a paper to sketch our small example, this is the idea of the two screens we are going to design/code. This also works to identify the elements and components we need:
Based on this we need to create the following files structure:
All of those are empty (except the basic files I mentioned before), which is ok for now. Let’s go to our designSystem.js file and make the necessary changes to accomplish something like this:
Accomplishing this, we have all our colors and typography types ready to be used in our components. Let’s start coding the basic elements, which are the smaller ones, you’ll be using these a lot in many contexts, that’s why in the proposed structure we are putting all this components inside the “Elements” folder. We can start with the Input.js, here we are going to design a reusable Input text-box, an important element for the forms we are going to build later. This is how the code looks like:
As you can see, we first call the things we need, the first two are something we are going to need always, the following dependencies are to call the designSystem.js. With this call, we can use our colors already defined before. Then we can go to design our Button.js element. Same logic, this is going to be something we can reuse:
Let’s make another pause. If you’re just familiarized with web coding, you probably are not relating this structure to a web code structure, and that’s because as we are designing “SketchApp” elements, we are using some React Native elements, so would be really healthy to take a look at it. Those who have worked with Fuse before, this probably looks more familiar.
We have our basic components for the exercise designed, so now we can continue with more specific components inside our screens, like for example the login and the sign-up boxes, which are going to be the main elements in each “Screen”.
This is how the code of the LoginBox.js component looks like:
Again, we are calling the elements previously designed. For example, with the elements <Input> and <RegularButton>, in just one line we are placing the element and changing the “placeholder” variable. Moving on, this is how should the code of the SignUpBox.js look:
And now let’s wrap up both in their respective screens. I know it looks like a unnecessary step, but imagine if your “Screen” needs to have more than one component or secondary elements besides your main component. Here is the example of SignUp.js
As you can see, in this “page” we are not just adding the SignUpBox component, we are also writing the values for the Title of the box and the Description labels. We are going to do the same for the Login.js screen. With both screens already coded, now is the time to export it and to render it into our Sketch file (we can do this meanwhile we are still coding of course, it is not a sequential workflow). This is how the main.js file should look like:
Finally, we call the pages from the main.js file and export the one we want to see in Sketch. For example, here we are rendering the SignUp page:
And there you have it, your design generated just with React. Here you are seeing just the Sign Up screen, if you want to see the Login one, just change the file name in the render code line. I know it’s pretty manual and rendering one screen at a time is limited, but I hope it can be improved in the future.
Oh, almost forgot it. Remember always to run the render with the command “npm run render”, if you don’t do it, you won’t be able to see the changes in Sketch every time you save you React files.
This is just a rough view of what this React tool is capable of, there are still a lot of things I personally need to test more, but I hope this small example can be an introduction not just to start working with Design Systems, but also I hope it can be an opportunity to try React.
NOTE: If you want to play with this demo, you can download it here.
Finally, let’s try to answer the initial question. Why all of this is worth the effort? Here some reasons I’ve found:
One of the challenges when you’re working on a big product, with a lot of releases ahead, is to keep your master file updated all the time. Or even more important, that each improvement can fit and be done smoothly. Being connected with a Design System that can allow you to maintain order in your design over time, it’s an effective way to do it. The most attractive characteristic of this React+Sketch tool is the possibility to maintain a master Design System for many future releases.
Speaking the same language with Developers
This is, probably, one of the most important of opportunities. A lot of the time developers and a QA team dedicate to detecting and solving visual bugs. React forces you to be accurate when you build your components, and beyond that, both, the master code and your master design system will have the same structure! What you have here is a reflection of the React code, so the implementation of a new feature should be faster (at least in Front-end). Of course, this opportunity is not one itself if the code don’t use React to do Front-end work.
An opportunity for collaboration
There are a plethora of ideas in the market to turn the design work into something more collaborative, from complete solutions based on Git logic like Abstract, until small plugins for Sketch. All of these ideas are still in testing stages, but working the design from the code, it allows you to use tools like GitHub, which are not just stronger version-control tools, but are also management tools. Imagine using Scrum to coordinate with your Designer mates!
Fetching real data
Another pain point which we deal daily, with the current approach, is the management of the data. It’s really primitive and typos are a constant issue. Imagine having all the content of your design in just one JSON file, where more people can contribute reviewing the texts and solving these issues independently from the Design. No more typos! This opportunity to fetch data also opens the opportunity to use an API, another step in order to make the Design work more integrated with other areas of a software development flow.
A more powerful prototype
I still couldn’t get the opportunity to explore this possible feature, but if we were able to put the code on a server like Heroku where we could perform basic interactions, goodbye InVision and Framer… maybe this opportunity is less clear, for now, but who knows what can happen in the future.
Yes, there are challenges. No blockers, just challenges that we need to be aware of, before even thinking about implementing this system in your current workflow:
The need for a “Full Stack Designer” profile
React is not easy, even harder if you as a designer doesn’t have experience with coding. It’s not impossible to learn, but if we want to make the process effective in terms of time spent, the need for Designers who are able to code for your team, will be more necessary in the future. I come from a full design background, so I know the challenges you could face to change your mindset and think from a coding perspective, a mindset that is quite different, where order and structures are key ingredients. I always wonder what is the future of this career as a UI/UX designer? Opportunities to work with tools like this one give me an idea. And I like it.
Is not the fastest way
As I said it before, we are practically designing with code, so if we are looking for something to design our small products faster, this is not the solution. This is made to maintain bigger products, where the need for a Design System is stronger. But don’t get me wrong, it is not the fastest way at the short term, but it gets more valuable over time.
The need for an integrated work environment
I repeated a couple of times; with this, we are speaking the same language with the Developers, but this also means a challenge to work closely with them, and in many companies, that’s hard to achieve for many reasons: logistics, separated areas, outsourcing, etc.
The tool is still in early version, there are a lot of limitations that I’m sure with the talent of the people working on it, and the contributors, they are going to be solved. But for now, we have to deal with them, for example, the limitation of just rendering one Artboard at a time, which is not a blocker itself (remember, in the old times, Photoshop worked and works in that way) but it can be a little bit difficult to get used to it, given one of the most attractive features of Sketch is to visualize all screens in one environment.
One more screen monitor
Yes, now the monitor where you probably are working needs to be split because it’s necessary to have your code and the SketchApp visible at the same time… and working with the Sketch in the half of the monitor is not cool.
Beyond how interesting it is to see these technologies working together, it’s still quite early to make a strong recommendation of using this right now. However, it’s definitely one of those things we should keep an eye on. It’s clear that the future of design involves developing techniques. It’s inevitable given the need for creating faster iterations, in a cycle where design has become a more important ingredient.
“My belief is that better products are going to appear, if these can be made from a more integrated environment, where all the areas can be able to work together, speaking the same language, following the same principles”.
And, finally, this wouldn’t be possible without the work of Airbnb. The efforts like this is one the reasons why working in this industry is exciting, the constant evolution of the processes and technologies we use, it pushes us not just to learn new things everyday, but also to think of sketching the future of the field ourselves. So, a big cheers to them.
Thanks for reading!
PS: If you want to know the most recent advances, I highly recommend to follow Jon Gold.
Note: We would like to thank Eder for contributing to our blog with his article.