medium bookmark / Raindrop.io |
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 big, 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 effective using components. Actually, symbols are just a primitive way to structure an usable component-based system, although following that effort, React is a more powerful framework, but for obvious reasons, is not related with the design work at all… until now.
The team of Airbnb has been working on tying 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 really interesting.
I’m not a developer, but I like to code whenever I can. React has been something I’ve been 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 some advice to build a real, dynamic and (I hope) a powerful Design System.
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, nothing of this would be possible without the amazing efforts of Airbnb, so I highly recommend to review the official GitHub repository here.
Besides the information you can find there, it’s 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, 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:
4. 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.
5. 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. Doing that, should appear an option to run it:
6. And finally, if you want to see how the example looks like, go back to your console (be sure you’re inside your directory) and type:
You will see how your Sketch file has been updated with the Styleguide elements of the example, all what you’re seeing has been generated by the React code. If you don’t have too much experience with Javascript and/or React, the generation of this content can be a little overwhelming if you check the code, but don’t worry about that for now.
NOTE: If you still don’t have a code editor. Atom is a really good and nice option, it has a pretty decent UX.
7. All the work we are going to do, will be performed only in the “src” folder. So go there and delete:
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 Typographies styles. For example, if in the future you want to update a color, this is the place to do it (and it will be changed in all 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.
Before to continue, we need to be sure what we want to do with this tool, how is going to interact with Sketch and how is going to be our workflow. Given 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 the React + Sketch project as a master, as the Source of Truth for the product you’re working on. Which it 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:
This very importance part, it’s what I called a coherent and well thinking iteration flow. A key component of this proposed Design System.
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 an 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:
General Structure
The key here is to have a coherent way to manage your components. Even with Sketch symbols, it can turns 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:
Components Structure
If you are working in a team with Front-end Developers. Ask for an advice to them, it would be really helpful in order to be in the same page, this will reduce the gap between your work and the Developer’s work, or in other words, you as 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.
Before to 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 typographies 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 call first 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 to 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. For whom have worked with Fuse before, probably this is more familiar to them.
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 it looks the code of the LoginBox.js component:
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 looks the code of the SignUpBox.js:
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 how looks for example the 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 time to export it and to render it into our Sketch file (we can do this meanwhile we are still coding of course, is not a sequencial workflow). This how should look the main.js file:
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:
The render in Sketch of the SignUp page
And there you have, you design generated just with React. Here your 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 it’s 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 to do, 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 is all this effort necessary? 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.
Probably this is one of the most important opportunities. A lot of the time spent by the developers and a QA team, is to detect and solve 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 mirror 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.
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 a 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, are also management tools. Imagine using Scrum to coordinate with your Designer mates!
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 have all the content your design is going to have in just one JSON file, where more people can contribute reviewing the texts and solving this 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.
I still couldn’t have the opportunity to explore this possible feature, but If we can be able to put the code in a server like Heroku where can be able to perform basic interactions, goodbye InVision and Framer… maybe this opportunity is less clear, for now, but who knows what could happen in the future.
Yes, there are challenges. No blockers, just challenges that we need to be aware of, before even think about implementing this system in your current workflow:
React is not easy, and even more if you as designer don’t have experience with code. It’s not impossible to learn, but if we want to make the process effective in terms of time spent, the need for Designers 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’m always wondering: how is going to be the future of this career as UI/UX designer? Opportunities to work with tools like this one gives me an idea. And I like it.
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, is not the faster way at the short term, but it gets more valuable over time.
I repeated a couple of times; with this, we are speaking the same language of the Developers, but this also means a challenge to work closely with them, and in many companies, that’s hard to achieve by many reasons: logistics, separated areas, outsourcing, etc.
The tool is still in a 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 feature of Sketch is to visualize all the screen in one environment.
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 is to see these technologies working together, it’s still quite early to make an strong recommendation of using this right now. However, it’s definitely one of those things we should keep an eye on it. 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 possible with the work of Airbnb, are efforts like this one the reason 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.
Be the first to write a response…
prototypr.io
AI-driven updates, curated by humans and hand-edited for the Prototypr community
