Introducing — 🕹️ Joystick... the Design System I made for Butn.
This is a 3-snapshot look into a design system I built that had two novel interventions:
-
Creating a new design system covering all product flows, but with the added functionality of also housing 3 generations of those designs - Live, 1.0 and 2.0.
-
Utilising the Design System as a high fidelity prototyping playground for teams both in and outside of the design team.
Why? —
During the early phases of an idea, the ability to take set of diverse team members into a realistic environment and work together on it, means you can proactively combat many sticky problems earlier on.
Having current & hi-fidelity screens ready to go on day 1, allows people to express concerns, unseen opportunities and their unique expertises more efficiently. Furthermore this also helps set realistic expectations, if we were to push forward on a given idea. This is where core insights like dev investment or realistic number of initial users, can drastically change or define the scope & implementation.
The team can now consciously decide how much to invest among current and future priorities or if too move ahead at all. At this stage the power of transitional design systems come into play, allowing for a new flexibility in delivering the ideas alongside improvements.
TLDR: how did it go?
It halved the amount of meetings during ideation and did so with better feedback specificity, however the real win was eliminating as much product development regression as possible. Faster iterations & confident sign-offs meant more efficient use of everyone's time as well as also improved team morale.
For the specific strategies used, continue reading.
The Mission
How might we reshape the pipeline toward meaningful product improvements, scoped in digestible formats that can thrive within a fast paced & resource short start-up environment.
Snapshot 01 — Good Groundwork... Works.
Transitioning away from a pivot heavy mindset, Butn began to focus on optimising successful flows to better serve existing clients with only minor tweaks toward new partners. Shifts like this are really important to look out for but often hard to spot as it usually happens slowly over time.
For Butn, this meant the design development, documentation and delivery pipeline, which was previously very pivot friendly, would benefit from a shifted focus toward optimisation & long term refinement.
Now I admit, these are less sexy than many of the other interventions, but they are also what allow for the more complicated changes to be possible within teams. If your organisation already has this, that's great! If not, time to roll up your sleeves.
Overview of groundwork strategies include:
-
Using notion to map and create a more interwoven design to development pipeline. Encompassing request, priority matrix, change logs & documentation for all things design.
-
View points for the different generations of the transitional design system that are being worked on, for better developer understanding.
-
"Component-ised" Guidelines and presets of guidelines built for different scenarios to maintain consistent & predictable decision choices.
-
Creating a guide for how-to-use the TDS, for both internal designers & external collaborators from partners.
Snapshot 02 — Why investing in a Transitionary System was worth it.
With developer resources being so precious, the choice between improving the current experience versus new client-seducing features is always at tension.
In the case of Butn, quality of life improvements often got crunched away. This became a core pain point in both developer workloads and expectations & communications for leadership toward clients. Providing a strong motivation to create a way for the many improvements to be shipped over time.
So what is a Transitionary Design System?
A TDS is a more structure intense design system encompassing all three (current, next & future) generations of the product. Using models like the Atomic Design System & design tokens, the idea is that you can selectively deploy improvements alongside new features.
By taking a generational view on how components and features are designed, we can prioritise design tokens or specific properties. Working closely with the development team, this flexibility let's us confidently determine effort versus reward with a longer term lens. Satisfying the common priority gap between the two teams.
i.e Improvements range from changing a single colour hex code, all the way up to a whole organisms (like a window or screen), with changes in layout, assets or logic. This allowed the calculation of the pain versus benefit over a longer period, versus the needing to fight and carve out a specific "overhaul" periods.
This allows design & development teams to "sneak in" consistent improvements alongside current high priority items (don't tell the higher ups, but they'll thank us later).
Atomic Examples in a Transitionary Design System
Snapshot 03 — Inviting organisation-wide play inside Figma 😱
Normally, letting anyone from outside the design team into the Design System is a recipe for disaster. However if you build for it the benefits are immeasurable.
A crafted playground for members that actively sell the product, or have a unique perspective on its stakeholders, bring out new avenues of value. Using multi-layered components and pages, this is where new ideas can quickly start. Teams can collaboratively explore changes & new features:
-
Fast & flexibly.
-
While retaining a consideration what's been made, and what deviations will cost.
-
As well as turn out high fidelity prototypes, that are ripe for partner testing and approvals i.e MYOB.
As a result, requirement gathering sessions and steps required was effectively halved. More people felt heard and most importantly, ideas stayed out of the development pipeline until they were ready.
Other problems resolved:
-
Ideas & Flows we're scattered and regularly being lost.
-
Lacked effective tracking and oversight into the many flows & variations.
-
Confident and specific knowledge was silo’ed to certain team members.
-
Less changes requested during development.
For many development teams like the one at Butn, migrating the design system to be the centre of work is an unfamiliar practice. So an important pre-requisite of success is weaving together buy-in. Addressing concerns and taking requests is just as important as the file itself.
Adopting Design Systems Presentation
TLDR, this covered
-
Why the change,
-
What the structure is,
-
How they would interact with it,
-
and the benefits.
Snapshot over!
Thanks for reading, got questions into the deeper detail of this project?
Send them through at Hello@clems.studio
\\ C—Log \\
Butn was a breath of fresh air for me -
From being compelled to go above & beyond scope squeezing in better strategy or solutions, to having a real platform to discuss, propose and then carry out massive interventions. This design system is one of those interventions and it's goal of expanding the DS core role into ideation & development contexts was a seriously gratifying experience.
Alongside rebranding the company my time at Butn has led me to a horrifying realisation - if your willing to put in the extra work, lobbying for change isn't only helpful to design change... it's required.
Shoutout to Will Donovan my mentor during my time @Butn,
he has changed the way I carry out & express design change.
