Lately, a small storm has been sweeping through the design team. The smatter of keyboards ring passionately in the halls, Slack channels drown in lengthy discussions, and the coffee pot runs dry from watering frustrated debaters.
The big fuss? Whether or not it is possible to create reusable systems and processes for UI design.
In the propagating camp: a handful of designers with a UX focus. The team rallies behind the manifesto-like nature of “design systems, not screens”. Eagerly welcoming ideas like Atomic Design, Object Oriented UX, project playbooks and the sharing of processes, we (alas! a biased author) are insatiably curious about how we must evolve as designers in an ever-changing landscape of multiple platforms and devices.
Design systems are not just about deliverables that can scale and adapt to the future — but also about creating systems for collaborating with each other on projects, being able to use and reuse pre-existing work and templates to eliminate unnecessary time in projects that are becoming more and more complex with every new development in the digital world. We fill dropboxes to the brim with digital lego pieces to be taken out and used for the right building: wireframing kits, templates for presenting insights, workshop kits etc. We are constantly considering how we can design and adapt tools to improve our work.
“Comrades,” we cry to the Art Directors and Visual Designers: “come join our Structure Utopia!”
But are met with, at best, a lukewarm response.
We react with affront. “But every time you take over a project you start with a completely blank document! Isn’t that a complete waste of time?” (we conveniently forget that our own process often starts on blank pieces of paper.)
The opposition is firm. “How could we start with the same document for each project? Every project is different. The whole point is to create a unique look for each product — you can’t reuse parts of another project without risking that everything looks the same!”
Team Structure is not convinced. “Why not start with a very basic library, like our wireframe kits? Lets say you pick the colours, add some basic components: make sure you have all the building blocks for when you need them?” We point to examples like Nordnet’s application of an Atomic Workflow to their UI design, as well as Airbnbs and Pinterest application of a global visual language to all their products.
Team Freedom protests. “You think these guys started out with that sketch file? They probably worked out the structure afterwards, and polished it up for the medium article. You can’t start a project like that. If you do, then it’s easy to lock yourself into a bad design, and you keep running with the bad design because it looks so structured, it must be right. You get stuck in your thought patterns: the checkbox has to look like this, the slider has to be horizontal…when you could have been doing something fresh, something innovative. Look at how they designed Hearthstone, without thought of scalability. You need freedom when sketching to find a good direction — structure can always be applied retroactively.”
Team Structure sighs, knowing that there’s a point to the argument. “Ok, we see what you mean. The trouble is, too little structure can be a problem. When working together, every designer can’t have their own system of naming and grouping, everything can’t be “sketching” — it makes it near impossible to take over someone else’s files. We’re not trying to strangle creativity. What we’re trying to achieve is that anyone in our design team should be able to take over anyone’s files at any point, and keep working efficiently. ”
Team Freedom concedes, cautiously. “When it’s a file several designers need to collaborate on, it’s important to have structure. However, in the sketching stage, it’s more of a hindrance.”
We reach a brittle resolution.
It is a conversation we will continue to have over and over again, constantly striving for the right balance. It is part of an ongoing conversation that is bigger than our team, a conversation that is happening everywhere.
When it comes to creativity, where does the need for freedom end and the need for structure begin? There is no definite answer.
The struggle between the two camps is not unique to the problem of reusable UI processes, it is present in all creative endeavours. It is also an age-old question. There is such a thing as too much freedom, and likewise too much structure. It permeates everything from what constitutes a good brief, to what tools we choose, to how we present our work.
At the very least, the team has agreed on the need for a shared structure — but to what degree, and when will it be applicable? We’ll see when the storm settles.
Have you had similar discussions in your team? What is your point of view on the question? Let us know!
I work as a UX Designer at Apegroup where I help companies create beautiful digital experiences. We are a design and technology agency in Stockholm. Want to know more about how we work with design? Read more at our website.
If you enjoyed this article, please press Recommend below!