Having a well-designed design system can improve your UI design work efficiency. Choosing an appropriate design tool doubles the effect. What needs to be considered before migrating a design system to another design tool? How to document your UI design in a way that everyone understands? In this article, I will talk about what I learned from a UI design project.
Design system migration: Mapping the current situation and choose a suitable design tool
Last year I worked with my colleagues on updating UX and UI for several applications, including the design system. The design system's original version was created by Sketch, but we decided to use XD as our new design tool. The reasons were:
Real-time collaboration. XD launched its "Coediting" feature before our project started. It allows multiple designers to work on a project file at the same time. But it didn't have such a feature for Sketch at that time.
Prototyping, sharing, and commenting in one place. XD has built-in functionality for prototyping, creating shareable links, and getting comments from anyone you share with the link. But in Sketch, you have to share prototypes combined with Invision (now Sketch has improved this experience).
The process of migrating the design system was easy, just to open the Sketch file with XD. Most of the components kept the original appearance, but some of them lost their styles. For example, an outlined icon with color overrides may turn into a filled icon when it is opened in XD. And a simple icon could have plenty of unnecessary layers when it turns into an XD component. In this situation, creating a new component saves much more time than fixing an old one. But we wasted some time making new responsive input fields because we were not so familiar with the responsive design mechanism in XD.
Some people may wonder why we didn't use XD2Sketch, which can easily convert file type and preserve everything with minimal rework. Because it was not worth spending too much money to convert a file that would have a big update soon.
The migration process may be affected by many factors, such as the current design system's condition and which design tool you want to migrate to. If you plan to migrate a design system, try to answer questions like these beforehand:
What's the quality of the current design system? Are all the elements well organized and named? Disordered organization and naming rules will cause unnecessary trouble for your future work.
What content needs to be migrated? Every design system migration could be regarded as a thorough cleaning of unuseful assets. It's not necessary to move everything to the new design tool.
What's the long-term design system plan? Will the design system be used for creating only several products or a bunch of different products? The long term plan may affect your choice of the design tool.
What could be a challenge/risk for your design work if you use your selected design tool? It's essential to know your design tool's flaw and make sure that you can handle unexpected situations. In the following section, I will write one example about this.
Work in progress: Keep an eye on the ownership of design files
As designers, we like to compare similar features in different design tools, but we rarely discuss those tools' abilities to deal with "risks". For example, failing to find a historic version, the program crashes during the work, transferring ownership of files, and so on.
During our project, one colleague left the team. Most of the XD design files were created by him, so he was the only person who could update shareable links for review. We asked the Adobe XD customer service if we could transfer the ownership to another team member at that time. But unfortunately, until now XD still doesn't have such a function. We never thought that the ownership of design files could be a big problem for the project.
In XD you can't update or create links for review if you are not the owner of a document.
To guarantee the latest design could be shared with the project manager and developers through links, we had to choose one solution from the following two:
Duplicate both the UI design file and the design system file. All the components in the duplicated design system file have to be unlinked from the previous file manually and make them into independent components again.
Migrate the design system from XD to Figma. It can transfer the file's ownership to another team member.
In the end, we chose the first solution. Because we had completed nearly 70% of the project by using XD. If we switched to Figma, we would spend a lot of time doing repetitive work, just like migrating from Sketch to XD.
The ownership transfer issue in XD has existed for four years, and no one will know when XD can fix it. If you are going to do a long term team project in XD, you should consider this issue carefully.
Design documentation: Make your design more understandable
Different people interpret design differently. Well-organized design documentation can help the team members understand your design better.
You can´t only throw your design file to the developers without writing any documentation.
Once, we delivered a table design to the developers. As we had already had a design clarification meeting before, we thought it was enough to send them only the updated design file's link.
The design file
But when we saw the result in the test environment, we had to say, "It was quite close, but could be better.
The same design has been used in two products, but different developers interpret the design differently.
In the new project, we started to write detailed design documentation on the project Wiki page, with related component links from the design system Wiki page. In our project, a screen update documentation usually contains:
Description of the latest changes (if any)
XD link of the screen prototype
User interface layout & example
Links of existing components (if any)
Parameters/ states/ visual examples of new components (if any)
SVG file icons (if any)
User interaction(if any)
By reading the design documentation, the developers could get a whole picture of what components had already existed and what they needed to code by themself. As a result, in the test environment, there were fewer UI mistakes than before.
How we link related design resource to the project Wiki
But updating newly designed components documentation is quite time-consuming. And adding too many links to the project Wiki is also not reader-friendly. To follow the project progress and keep the project Wiki easy to read, we usually only create new components in the XD design system file, and document them together with a related user interface design on the project Wiki page.
We usually work without updating the Design system Wiki
Design documentation is not only used for communicating with the developers but the whole project team. Here are some tips for writing screen design documentation:
Keep it short.
Keep structure consistent in each subpage.
Use simple language and short sentences.
Use tables flexibly to explain the design.
Use gif if necessary.
Note down every update. The latest date is always on top of the page.
Avoid repetitive explanation. Use `See XXX' `The same as XXX` (XXX is the content link that you want to mention again)
Go through your documentation again after a few days. Do you still feel clear about the documentation you wrote?
Conclusion
Building a design system can faster the UX/UI design process. In the meanwhile, each UX/UI project contributes to improving the quality of the design system. Creating a high-quality design system such as Material design or Carbon takes a lot of effort, time, and resources. But not every design system should be like that. Just build one that fits your needs. If your team's work progress is fast, it's no problem to only focus on updating the design system file (such as an XD file) and write documentation later on.
Writing design documentation can be taken as a part of your communication with the project team. Unlike the design system documentation, UX/UI project design documentation needs to be up to date with the project's progress. But no matter what kind of design documentation, build a clear structure and consistent style for each page. Do a self-review to evaluate the reader's experience. Get feedback from your team members and make it better.
Comments
Post a Comment