- How to Save UI Designers & Front-end Developers up to 50% of Their Time
- By Henry Latham
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: meterscao
- Proofreader: Rockyzhengwu, Park-Ma
Why is There Christmas in January
Hint: This article has a lot of funny and boring memes, as well as a lot of big pictures. Unless you don’t care about data charges, it’s best to connect to Wi-Fi first. And this article is really long, and you can have a bucket of popcorn and coke [laughs].
Christmas in January?
When you’re a kid, Christmas is really, really exciting. The thought of the presents Santa brings, and the scene when they are opened, fills the whole month with unimaginable excitement and joy.
In my career as a UI designer, I was as excited as a kid when I first used Sketch App:
“Are you serious? ! I’ve probably wasted 90% of my time in Photoshop in the last 3 months with stupid little pixel graphics that don’t even look the way I want them to. Why didn’t anyone tell me about the App before? ! It’s unbelievable.”
AS a designer, THERE are only two stages in my career: life before Sketch (BS) and life after Sketch (AS).
I don’t want to say life before Sketch was awful. Everything looks… It’s different, it’s weird, uh… It’s a little pixelated. It takes almost a week to design a headline, let alone a whole page.
Life with Sektch is not so cool. I bet you could even start a design team with a bunch of kids.
You can reuse various elements. They are beautiful, vectorized, organized, and very simple and intuitive.
Well, if you’re a product manager, designer, or front-end engineer, you’re as excited as a kid right now.
It may be early January, but I feel like Christmas. Welcome to the world of object driven design.
Author’s note: As I write this in Jerusalem and the West Bank, I see some Christmas trees still on display…… Since then it has been noted that some Orthodox Christian calendars have Christmas actually in January. And then found my title a little ridiculous and eye……
In this informative and fun post, I will explain:
- What is object driven design
- Why are these problems still unresolved
- Why is it risky not to use object-oriented design
- How to adopt object-oriented design in the design process
My approach allows UI designers to spend more time doing happy design, and allows front-end developers to focus on features instead of tweching spacing pixel by pixel. The design-to-development process (WHICH I call “D2D” for short) will truly be tenfold more efficient.
Why do you care?
A lot of product managers and UI designers read this and think,
“I’ve been using the Symbols and Typography features of Sketch for 3 years now, say something I don’t know and then stop your stupid Christmas metaphors.”
They are not wrong. I suspect that most designers create reusable Symbols (similar to “objects” in programming jargon) in Sketch files at some point.
However, no designer I’ve worked with in the past two years has found a comprehensive way to improve the inefficiencies in D2D delivery.
There are three reasons for this problem
Before delving into the D2D issue, it’s important to understand why D2D is still inefficient when there are so many design tools out there.
1. Mediocre standards
Unfortunately, many readers will feel confident that this is not a problem for them or their companies.
Because productivity and efficiency are relative. Few UI designers and product managers realize that there could be a better design process.
We tend to benchmark ourselves against other startups and UI designers around us. It’s probably most efficient if everyone works the same way, right?
Not right.
One of the most common biases we have is to stereotype things in the world based on our perception of what we now call “efficiency.”
Here’s an example:
Suppose I’m a little overweight, but all my friends are fat. When everyone around me is fatter than I am, I’m likely to think of myself as a healthy person because my reference points (my obese friends) are worse off than ME.
However, just because they are not as healthy as me doesn’t necessarily mean I am. I’m still overweight.
Therefore, in order to make a significant leap in efficiency, it is necessary to break the standard of mediocrity and try to innovate.
“If I asked people what they wanted, they would say faster horses.” — Henry Ford
2. Blindly trusting existing processes
One of the reasons D2D inefficiencies persist is that we always assume that the processes and methods we use in our company are already optimal.
But that’s not the case.
First of all, there will always be inefficiencies, whether or not agile development ideas are truly followed. In particular, there are some that you may not even be aware of.
Second, you must be aware that without a unified system of collaboration and competition, projects immediately start to “compete for resources rather than collaborate effectively,” as LeanUX author Jeff Gothelf describes it.
Such scenarios often mean that designer resources become scarce, often shared between a few product managers and a large number of programmers. Designers work on multiple products and developments, which can lead to confusion and disorder in their collaborations. As a result, UI designers are rarely able to stop and try to do some systematic design to make it more flexible.
Only by following the object – driven design process can we achieve true speed and agility.
3. Designers and programmers are completely different people
In our fantasy, designers conduct weekly design reviews and reviews, and all-powerful product managers communicate and coordinate effectively with everyone. Yes, it’s easy to test if you don’t do it, but it’s hard to know how.
It boils down to this: a fundamental misunderstanding, or professional gap, between UI designers and front-end engineers.
UI designers tend to think of themselves as artists and their work as works of art. As long as users can understand the beauty in their work, their products can reach millions of users.
They love typography and are passionate about crafts and hand-brewed coffee. Their favorite color is #FEB4B1.
Programmers, they just want to make cool stuff, they don’t care too much about what it looks like and how it looks visually. For them, the elusive concept of style, left to the artist, is as foreign to them as dating. They don’t understand why the shade of red is redder or why the headline text should be a little bit to the left.
They are happiest when they are left alone to write code for some complex new project.
They are fundamentally different people. Different professional skills, different ways of thinking, different interests and hobbies.
Each sees the other’s area of expertise as incredibly complex and convoluted. So they avoid interfering in each other’s territory at all costs.
Perhaps neither group knows, or frankly doesn’t care, that there’s a lot of overlap between the UI designer’s visual work and the front-end engineer’s.
Based on this, the D2D process would be very simple and fast if the two characters established an explicit design language (i.e. Symbols in Sketch).
However, since each role is not interested in working in isolation from each other, there is still a significant knowledge gap between them, which is another reason for the team’s D2D process to be inefficient.
Therefore, it makes sense for UI designers and front-end engineers to use a common design language to improve inefficiencies:
“Models that produce good results should be promoted, and those who cause problems should be corrected.” — Jeff Gothelf, author of Lean UX
4. Problems with not following object driven design
1. The absence of a design system wastes a lot of time for designers and programmers
UI designers
In theory, the D2D delivery process should be straightforward.
In theory, UI designers are already on the same page with front-end development and can work seamlessly together.
In theory, they agree on a common design language in advance and use reusable components and elements. A designer can copy and paste it in Sketch and develop a line or two of code on the front end.
However, theories rarely translate into reality.
The reality is that most UI designers spend a lot of time designing new custom elements.
First, because they’re not programmers, they don’t understand how much extra work it takes to implement these new design elements.
Second, many UI designers think of their work as art, not science. So they are not willing to sacrifice beauty for pragmatism.
They prefer to spend a lot of time making small tweaks to existing elements, rather than delivering easy-to-implement designs to front-end engineers as quickly as possible.
They spend too much time and energy on details (like moving text a few pixels) instead of focusing on the project (like designing and experiencing a new feature).
Details are important, but when existing UI elements are already well suited to requirements and scenarios, it’s hard to prove that tweaking these details will actually lead to significant improvements.
The problem is exacerbated by the fact that the UI designer’s obsessive attention to detail slows the project down. Design reviews are delayed, information from product managers is not synchronized, and designers are willing to spend more time on their own design work.
Front End engineer
By the time the front end engineers get the final design, they should have gone through several rounds of reviews to make sure everyone is clear on the final expectations.
However, we still find that problems still exist because:
- Front-end engineers put too much faith in the design draft. They often assume that the final result must be exactly the same as the design, and although some designs are difficult to implement, they treat all UI designers as experts. Therefore, instead of trying to simplify or discuss the design, they believe that there is a good reason behind everything and that the UI designer’s draft is the perfect solution.
- Front-end engineers hate meetings more than anyone else. So they don’t want to have a long and boring debate about whether the font size should be 12px or 14px, they just want to get out of the meeting as quickly as possible, agree with the designer, and happily get back to writing code.
- Front-end engineers tend to be introverted and shy. As a result, they are less likely to compete with confident product managers and overconfident UI designers.
As a result, despite early design reviews and discussions, they end up doing things that are repetitive, unreasonable, or difficult to implement.
2. D2D becomes less and less efficient over time
The longer D2D remains inefficient, the greater the waste of resources on current and future team members. This may seem obvious, but it’s often overlooked.
We tend to focus more on short-term goals (working overtime to get things done) than on long-term goals and ultimate success.
In the midst of short sprints and massive project features, there was no time to address collaborative inefficiencies.
Because it’s easy to focus on short-term goals, because we’re all under so much pressure, and because we rarely stop to think about the real purpose of our busyness.
3. No design system = Design flaws
The less systematic a UI designer is in the design process, the more problems he or she will face later in the process.
Let’s take an example:
Suppose all the ICONS don’t have the same size. Some are 24×24, some are 40×24, and some are 12×16. Not only is this a waste of programmer time (as I stressed in the first point), but it also means that any future changes can be very cumbersome. If you want to change some ICONS in the future, you have to redesign and export each icon for each specific size, otherwise the ICONS will either misfit or be stretched in the final display.
In addition, if UI designers don’t create strict text styles, color palettes, and reusable Symbols in Sketch files (for example, all buttons are 24×24), it can seriously hinder the efficiency of editing existing elements.
If we wanted to adjust the text style uniformly across the product, we would have to manually adjust each page in Sketch one by one. But if Typography is used, it doesn’t have to be. For a full App with lots of pages, such tweaks and updates can waste a lot of UI designer time.
4. Not having a design system hampers teamwork
Without a design system, UI designers spend most of their time creating new elements or constantly modifying existing designs.
This means they don’t have much time to brainstorm or try out new ideas with front-end engineers in Sketch.
The team can organize design reviews to test different solutions or tweak the design under discussion, which is very helpful for the entire team to invest in and support the design.
“Teams that consistently give each other feedback create better products.” — Jim Semick, InVision
In addition, the design system saves a lot of time for the entire team by eliminating the need for UI designers to go through repeated design reviews and rework for the same solution.
How to implement object driven design
By now, hopefully, you understand how important it is to implement a design system.
In the next section, I’ll discuss the importance of changing the way UI designers work before delving into the details of building and maintaining design systems.
Step 1: Take ownership of the D2D process
Before committing to object-driven design, ensure that UI designers are properly incentivised.
If their reasons for doing it are vague: “It makes the team more productive,” “We’re just being asked to do it,” if so, forget it.
However, if designers genuinely accept that the D2D delivery process is a critical part of their role and responsibility, they are more motivated and motivated not only to build a design system, but to maintain and improve it over the long term.
Let me emphasize this: building a design system is not just a one-off task. Whenever you start a new design or validation scheme, you should organize them exactly into your design system so that they can be used in the future.
UI designers must fully accept that they are responsible for D2D processes. Otherwise, they are not particularly curious and invested in how to implement design programmatically to improve the design process.
They need to read articles about the Design and development process, take basic programming courses, take Material Design guides, learn about front-end engineers, learn from product managers, front-end engineers, or other designers, and so on.
In short, they need to get out of their comfort zone and not abandon more important learning in order to focus only on what they like and feel comfortable with, and not end up reverting to Sketch and Dribble.
Step 2: Build the design system
The core purpose of the design system is to create a complete list of elements based on object-oriented programming. The hope is that the design system you create in Sketch will allow designers and programmers to work more closely together, which will make the whole team work more efficiently.
Communication between designers and programmers leads to a deeper understanding of each other and leads to better products for the whole team.
1/7 Start with the basics: colors and text styles
Object-driven design must start with the basics: defining colors and text styles. Because all other elements need this information: for example, a button needs to specify the background color, the border color; A line of text needs to specify the font, size, and line height.
2/7 Create a separate control for a single page
By creating a sample page, you can quickly understand the principles of object driven design and guide how to apply them in the real world. In my experience, learning how to build a complete design system can only be done by iteratively practicing object driven design theory.
Don’t be afraid to be incomplete when you start trying. Because once you’ve created some sample pages, you’ll quickly understand how to create them properly.
You can start with a title bar (a title bar with text and buttons), a paragraph of text, or any other control you want to try. Keep in mind that consistency starts with the smallest element.
An element is a set of Symbols, such as a title bar or paragraph text
- YouTube video link: Youtu.be /5MGNi24hHAE (no longer open)
3/7 Override (Changes the element’s information)
If you select a Symbol in Sketch, in the right pane (in “Override”) you can see the information that the object contains that can be modified, such as the text contained in the title bar.
Note that this change does not change the style of the Symbol itself. Because this is essentially how the front end works:
You define the interface to present to the user (for example, font size, typography, alignment, and so on), but the final content to populate (for example, name, address, icon, and so on) is pulled from the database.
For example, you can specify the location and size of the image button, but the actual image displayed is stored in the CDN.
4/7 Create a set of sample pages
Now that you have seen the power of Overrides, you know which types of Symbols need to be created and how they are related and combined (e.g. buttons in the title bar).
I hope you realize how well planned and organized this process is. You may have already defined some Typography yourself, but I wonder if you just created a variant for left, middle or right alignment.
Now try to create 4-5 pages, all of which can only be created based on the Symbols defined earlier. Don’t worry if they are poorly organized or poorly structured: being aware of them, learning from them, and thinking about them, is essentially a learning process.
5/7 names the Symbols exactly
You should now have a clear understanding of how to create a complete design system.
But before delving into the full design system, I recommend spending some time understanding the information architecture.
Information architecture is essentially about organizing information in the most logical and optimal way.
In the case of a design system, all objects are in a clear hierarchy, have logical names, and common elements are easy to use.
Before building a comprehensive design system, make sure you are familiar with the whole product, know all the Symbols you need to create, and know how to best organize them. Which elements are most commonly used? How can other designers find these Symbols? How would they expect each Symbol to be named?
If the above points cannot be achieved, it will take a lot of time to find and rename Symbols in the future, and it is also impossible to add new Symbols in a logical and clear way.
6/7 Create a comprehensive design system
Now that you’ve created some Symbols, have a clear idea of which Symbols you need for your product, and have a clear naming system, it’s time to complete the design system.
In order to keep the structure of the design system clear, you need to set aside dedicated time to complete it and be fully committed to it.
As you finish, you may find some naming errors and bugs. So feel free to check your naming conventions, create pages for testing, and verify consistency.
Because your product is unique, the Symobls you need to create are also unique. So you have to think about how best to structure the design system and what exactly the system needs to include.
7/7 Design review
Organize design reviews with product managers, UX/UI designers, and front end engineers to present new design systems.
You’ll find that all members of your team will immediately recognize its value. Front end engineers are happy because they have a clear delivery document to refer to and use; Product managers are happy because they can prototype quickly with designers. Other designers are also happy because they can all work together in the same design system within Sketch.
Once you’ve saved your design system to the “Template” in Sketch and shared it with other UI designers, you can open a bottle of wine and celebrate.
Step 3: Maintain your design system
Once you’ve designed the system, you need to keep it iterating forward.
Any new design elements, whether or not they make it into the final product, should be properly grouped and organized as Symbols.
Chances are your work is so busy and the pace of the project is so fast that you won’t have the opportunity to reassemble the final design piece by piece into Symbols with a well-defined naming convention. Rather than waste more time in the future, design in an optimal way from the beginning.
No matter how busy you are, please remember that sharpening your knife does not miss cutting wood.
Also, if you have other designers on your team, you all need to contribute to the development of the design system.
Every member of the team must follow the design specification. There should also be a designer responsible for adding new Symbols to the product’s “Library” to ensure that all the existing and new Symbols can be accessed by everyone.
The designer should also update the files on the trunk regularly so that all team members can access the latest version and avoid wasting any time by not saving the files. I recommend using Github or Sketch Cloud. You can also use the paid Abstract for a more intuitive and designer-friendly way to manage the version of your document.
If you are just a small team, there seems to be less need for this kind of organization. But at some point, you might want to think ahead: how will a new UI designer know where to start without the latest design system? How do you work with each other?
Step 4: Innovation never ends
As I said in Step 1, the core element of this process is responsibility. It’s easy to hold on to expectations. It’s hard to take responsibility.
But it is crucial to success.
You must be vigilant, constantly learning, and constantly looking for new tools to sharpen your skills and improve your workflow.
The Sketch App is constantly improving and the Sketch community is constantly seeing cool new plugins. Other design tools are also emerging, such as Adobe XD, that you can look at and try out.
The top companies spend 5-15% of their revenue on training their employees. If you’re a designer, stick to spending some time each week learning about new technologies and experimenting with new products.
Always remember that investing in your own learning and focusing on the company’s long-term goals is the key to success, not what seems urgent or important right now.
About the author:
Henry Latham, a freelance UX/UI designer based in Berlin, is looking for potential co-founders.
If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.