How Can a UX Engineer Help a Design System Team? Part 2 — The Build Up
OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we’ve shared a month of content on how our UX/UI Team tackled this project while building and implementing their very own Product Design System to create a delightful experience for all users.
As part of this series, we presented you with data on why illustrations add value to the interfaces of software products, courtesy of our Digital Designer David Monteiro; the Team Lead of the Product Content Team, Marina Calado, showed why writing the words that matter is vital to establishing a UX writing practice, and we interviewed our UX/UI Team Lead, Andreia Mesquita, about how OutSystems built its UX culture.
In the first part of this article, I shared my views on what it means to be a UX engineer and their main responsibilities while working side by side with Design and Engineering teams. In this article, I will deep-dive into my work at OutSystems by describing some of our UX processes, how we adapted across different projects, and what we achieved in the past year.
Creating a structured and well-defined design system is fundamental to help you sell such a framework within your company and highlight the value it will bring. This is why we chose a challenging starting point: one of the oldest applications by OutSystems — the Service Center.
Some of you might have heard about it as it was developed more than 10 years ago! Much like a pilot TV episode that helps sell a particular show, having pilot apps is perfect because you know exactly your priorities and where you should focus.
The Pilot Application
We have a decade-old application in our hands. Now what? We are aware of the impact that creating a disruptive change in this type of software will bring, as many of our users have been working with this application for a long, long time. So, we need to ensure that old users will have a pleasant new experience while new users still find it attractive and modern.
With some of the groundwork done — we synced the design and code according to the foundations we’d defined, and we audited the app -, we chose the top three most visited/used screens. Then, we extracted the primary components used, the basic inputs and controls, some tables and data, and the main existing styles.
Following this, we matched the old styles and components with the new design system we were building. After internal and external feedback loops with stakeholders and the team, we designed the first screens to be implemented. In the meantime, while management decisions were taking place, we continued designing and developing the first components to make sure they fit perfectly inside our product.
Finally, all was set for our first delivery as the Design System Team. We released the design files and code elements to the dev teams while introducing a completely new framework of components. And, just like that, the team had to learn how to use the new design system on top of a legacy system with more than 10 years while trying not to introduce any breaking changes!
It was precisely at this point that I switched roles from Design to Engineering, joining the Lifecycle Team as a UX Engineer to help them develop the app. The move was beneficial for us during the initial phase of the design system because it allowed us to improve and further define the system, but it also helped us with:
Advocating and Educating
As a UX engineer, by collaborating with the Engineering Team, you will have the opportunity to teach them how to use the system while also improving and supporting its ongoing development. The result? We end up with a new team that can fully build new products while using the system. Regarding advocating, it’s all about promoting the need and the importance of using the system and stressing its benefits and outcomes.
Collecting Feedback
While observing the team using the system, you collect feedback and change some components to make them easier to use in future development processes. You understand what works better and what needs to be improved in Code and Design and then bring back the feedback to the Design System Team to plan future work.
Building the Confidence to Succeed
Moving such a complex application to a new system and receiving great feedback from our users proved that continued improvement work on the design system would help us evolve and launch new products.
We have a Design System, Everyone Wants a Design System
As if this was not enough, different Design and Engineering teams were developing new tools and experimenting with the first draft version of the Product Design System at the same time. Use cases popped up both in design and code.
We focused on improving the system based on the pilot application’s feedback on the design system side. We also prepared for the future by taking in feedback from the experiments by different teams.
We were developing around eight different products/apps and constantly delivering features. Although the first version of the Product Design System was already in place, it wasn’t ready (yet) to escalate quickly. So, teams continued working on new features and designing specifications for new components. How did it end? A complete mess.
Apps that should have the same styles and behaviors looked and felt different. I’m not blaming anyone — we were doing the best we could. These mishaps happen, and it’s okay; we were one step closer to having a mean, well-oiled machine. We just needed to learn and overcome those issues.
So, we went back again to one of the pieces of advice shared in the first part of this article: we prepared the groundwork, designing and building all the necessary assets to accommodate every tool under development. We went through different stages during this process that helped us deliver the best experience for our teams and, most importantly, to our users!
Audit
By reviewing the work so far, you will once again have the opportunity to identify broken experiences and missing assets. Then, you can easily match those with the most recent features from the Product Design System while removing friction from the current implementation.
Awareness
Get involved with the teams and create regular syncs to show (and tell) what’s going on with the Product Design System. By doing this, our teams were able to:
- Better estimate their work without having dependencies on the Design System Team.
- Continue focusing on business logic instead of pixels (as mentioned in the first part of this article).
Make It Available, Reusable, and Open to Contributions
When all the pieces finally fit together, and we had a “final” version of our Product Design System — well, not final because design systems are constantly evolving, but I’ll leave that to a potential sequel of this text — it was vital to make it available and easy to use by everyone.
To achieve this and help different teams grow simultaneously, specific tools/assets from the Design System Team were fundamental:
- UI Library — A Figma file with all the necessary UI assets.
- Code Library — Ready-to-use OutSystems blocks on top of the OutSystems UI Framework.
- Product Design System Preview — An application where developers and designers can inspect and interact with the code configurations.
- Design System Documentation — More detailed and specific information about the entire system developed to build OutSystems products.
- Weekly sync meetings to understand the teams’ needs and collect feedback from the field.
Design System Today
Today, the Product Design System is the single source of truth and the baseline of any new development project inside OutSystems. In the meantime, we delivered a few more components and introduced a new theme for specific use cases. The best part? Teams are now fully autonomous to build their own components while using the foundations and the best practices from the Product Design System. And they do it more quickly and efficiently, providing a seamless user experience.
Is it mission accomplished? Well, yes and no. The work you put into a design system is never over. As your product evolves, so does your system, or you will end up with an obsolete framework.
That’s another peculiarity about working between design and engineering — in both these areas, your work is never done. You keep iterating, improving. And that’s a pretty cool thing when you enjoy being a UX engineer as much as I do.
Originally published at https://www.outsystems.com.
