A while ago I posted here why it makes sense to introduce a design system. Of course we also want a design system here at ePages. So we’re on it! How did we approach this? And what did we do so far? Continue reading… 😉
Realization
If you stumble across the same challenges over and over again, you’ll realize at some point that you need help. “Realization” came during our UI text sessions when we were confronted with new behavior, an element being used for something else than it was intended for, or “simply” disagreement about the target group. We reached a pain point where we desperately longed for a recurring theme that supports us with designing our user interface.
A fault confessed is half redressed.
Get the team onboard
Wait a sec. Who exactly is WE? WE, that is a UX Manager and a UI Writer. But of course these roles are not the only ones involved in the process of crafting the user interface.
We asked ourselves:
- Who else is involved?
- With whom do we have interfaces?
- Who makes which decisions?
- Who has to coordinate with whom?
So, we brought colleagues from Product Management, UX, Frontend Design, and UI Writing together and discussed about initial approaches to common standards.
Stocktaking
Knowing exactly what you’re dealing with is always a good idea. So we went through the UI and did a stocktaking.
- Which elements do we use and where?
- How are these elements designed?
- What’s their behavior?
- Which spacing, fonts, font sizes, or colors are used?
It was a lot of work - but absolutely worth it! We figured that there is indeed potential for standardization, and we wanted to tackle this together.
Single source of truth
Everyone has their own way of filing information and documenting decisions. It all adds up to a lot. There was information everywhere.
- In Sketch and Photoshop.
- In Phrase, Confluence, and Balsamiq.
- Somewhere on a local storage.
- On GitHub.
- Or just in the colleagues’ heads.
Clear thing: we had to install a single source of truth to bring all information to one place. The most obvious solution that came to our mind was to use the GitHub repository of our Developer Portal. All colleagues are familiar with GitHub and have access to the repository. We could file the information in Markdown, and also add images and GIFs. Another advantage: once we reach the point that our design system is ready for publication, we could easily do that via the Developer Portal. All processes are already in place.
Endurance is king
We want this to work. That’s why we have to be persistent in what we do. That means learn from our mistakes and document decisions, stick to our own guidelines, coordinate well with each other, and critically review what’s already there.
But we know that this is a big challenge for a small team. It needs an adjustment of our processes, requires time, and resources. That’s why we have not yet made it as far as we would have wished. But we are still on it.
Do you have similar experiences? Share them with us on Twitter.
Related posts
Why it makes sense to introduce a design system
About the author
