Imagine this, you work closely with developers and multiple stakeholders. We’ve been told it’s an ‘Agile’ project. Yet our workload is still ‘siloed’ within the design and development team. Marketing and management are not entirely on the same page as us. We ended up with unmovable deliverable deadlines popping up everywhere on our calendars, and still have to produce carefully crafted designs to get signoff approvals from the upper management to continue working. Sounds waterfall-ey for you? Well because it is! Image from Unsplash
In all honesty, even though in our little OCD-induced mind, this is not entirely ‘the right way’ to do things. You can’t put the blame on them. They pretty much have a lot on their plate dealing with multiple pressing matters on business’s side already. It’s not agile enough yet not entirely waterfall. This is where the term pseudo-waterfall comes in.
It is what it is
However hard it may seem, being a designer is always going to be about adapting to changes and how we can solve problems in the most efficient way possible. So to paraphrase Gandhi: ‘let’s not delve on the problem we can’t fix’, and instead focus our efforts on the only thing we’re born to do.
In the environment of working with large enterprises with many moving parts. The challenge here is not to build a design system, but the closest representation of it. We have to keep things going and iterate in chunks to keep the client engaged and on board with our work. After all, that is the least you could do to get it done professionally!
Firstly, stop looking at those beautiful references
As you delve deeper into the world of a buzzword that is ‘Design System’. You may have a notion that it is this gigantic, well-built, carefully thought out set of rules and a design ecosystem that you and your team must strive towards at all cost. You look at those beautiful systems like Carbon, Fluent, Material and you hope to be building one of those in your upcoming Digital agency’s projects. It’s what you should be aiming for, right?
No, Stop it!
The thing is, there’s no definite ‘right’ answer when it comes to building a compact design system for rapid deliverables. Let alone a pseudo-waterfall project here. So what should we do then? Here are the basics of it:
What you should consider when building a compact design system?
1. The project’s constraints
Is this a 6-month contract project or a long-term ongoing product?
Are they having tight timelines? Can they afford to wait for you to build it further?
Will they bring in multiple parties of developers to carry out your approved design?
Are you having enough time to onboard another designer(s) if needed?
These types of questions play an important role in the scale of your design system. Too small of a system and your work may feel inconsistent and falling apart as soon as you look away for ten seconds. Too large and overly ambitious and you will end up with 500+ useless rules you invented literally for no one. Guys...
2. Put it to use effectively, not religiously
Be mindful that you’re building a design system to have everyone follow it. Not for your own ego and building up your dream portfolio collections. Everything created should be beneficial to those working with you. The design system grows to correspond to the product’s ambitions and size. Not the other way around.
3. The others’ perception of the design system
All of these could be for nought if you cannot give your teammates the same notion when working on the project. Set the goals and expectations of your client, management, and even your team to make sure they know what it is and what they can do to contribute to an improvement. You wouldn't believe how easy your day-to-day work will become when everyone understands that they can jump in and discuss how to improve your system further. Rather than staring at it blankly and trying desperately to fit it into their ideas.
One of the most common mistakes designers make when working on a project is that they don’t know how and where to start building a design system. Let me give you a simple guide to follow.
1. The sooner you can build it, the better
If you can do it right at the start of the project. Go for it! To balance the time between delivering your designs and building up the system to keep everyone up to speed with your creativity and ideas is one of the challenges you will need to do.
2. Start small
You can be as fancy as you want about how you thought out colours for your buttons, creating multiple states of form input, defining the type of tones with your design’s language you used in your product. As long as it’s necessary and not over-compensating for the thing you may find very little usage in the long run. Creating 15 palettes of shades and tints for your 3 images of illustrations in the onboarding screens is NOT a good way to spend your time.
3. Be constructive
No one likes to work with a stale, boring, unintuitive system. Design systems were meant to grow and improve. When contributing to the system, consider these questions to be asked around constantly:
What problem does it solve?
Do we already have that specific solution in the system?
What impact will it have on the entire workflow?
If you can answer these questions and it still makes some sense to stakeholders. Then it could and should be implemented in.
4. Communication is key
Talk and discuss it, leave notes and explain everything clearly. There’s no way you can work on any system without talking or communicating with your team. Be ready to contribute and share comments and ideas on how you can improve and what we’re building upon.
5.Feel no shame using others’ inventions
This is not a contest for whoever could cook up the most elaborate systems within the shortest amount of time. It is meant to be a marathon of the carefully thought out structure as your work progresses. Spend your time looking up well-rounded and useful templates & UI kits to get you started. This is the core idea of having a system in the first place. To make modifications, stay on top of the tools and useful plugins to get you comfortable with it quickly.
Implementation practice
Now onto the most interesting topic. What is actually being done in our team?
At OOZOU we consider prioritising the colleagues' onboarding experience on these order:
Because we have multiple projects running across the team of 10+ designers. This is by far the most practical aspect of our design system at OOZOU. Some of these might seem a little wonky and unreliable. Yet we’ve been working using these methods and get it working to some degree. Due to the sheer amount of people getting a better notion of a ‘good’ design system, these practices may change over time.
To shorten the time-shifting resources along the project’s timeline. We consider these as our main goals:
Try to make it a self-explanatory system
A design system should be easy enough to understand and get used to. When a new designer starts working at OOZOU, They will be given the time and opportunity to study the basics and the way things work using our onboarding documentation before they’re cleared for any ‘actual’ work. However, you shouldn’t have to be a designer to understand these systems.
Leave a concise note as possible when it’s necessary. The challenge for us here is to build all of our systems to be as common as they could possibly be to allow basic guesswork if needed. Yet retains the flexibility and its own differences according to the product’s business nature.
If something sounds a little bit too complex, use words to explain it
Inevitably, some aspects of the system will still need to be explained and discussed. This is where communication comes in.
Because of the volatile nature of these systems, we are encouraged to ask questions of any parts we found ‘odd’ to a certain degree.
This method saves us a lot of work time than writing elaborate documents and having it hang uselessly on a small-but-may-be-medium-size project with only one designer working on it.
In any quick succession of deliverables, documentation is considered the commodity
Due to the nature of some timeline-tight projects, a quick note in the design file is preferred over long-comprehensive documentation. if you spent 3 sprints iterating the same set of components back and forth with the clients. By the time that UI element is on its 45th version, you will be doing 45x the work by rewriting and updating your components guideline!
Just be aware to balance it out between not leaving any notes and having some along the way. Because you tend to forget the journey of your discussions and would normally have to scour within mountains of meeting notes and JIRA tickets to recall them. To note and give others rationalisation between some modifications is worth doing out of keeping your own peace of mind intact.
However, if you are allowed to work on documentation, or currently on the verge of handing off the design system to external team/s. Consider allocating some time to write detailed documentation and guidelines beforehand. Don’t leave the poor souls confused and frustrated when you hand it over to them!
