Building the Kaleidoscope
Our first step towards a shared product language
I feel like we’re in quite a privileged situation at Qwilr. We’re an experience led product company, driven by principles that we actually live by. Not faded slogans on the wall, or memos circulated by a distant CEO, but something everyone working on the product has direct and shared accountability over. No arbitrary deadlines, unnecessary standing meetings, or processes applied blindly because “FancyCorp” did it. I think most importantly for us, if we’re approaching a launch and it isn’t going to deliver the value we want for our users, we decide not to release it. As a team we care about shipping things we’re proud of — things that we believe are “undeniably best”.
This luxury is afforded by lots of things. Putting aside the obvious — having founders who created the direction and environment for these principles to take root — a significant factor is the current size of the company. We’re 30 people, nearly half the company work remotely, but most of our product team are based in Sydney. While principles help guide our direction and what we focus on, they become harder to keep a firm grip on in the day to day design and development, as our product velocity is increasing with growing headcount. New perspectives join, the demands of the product change, and defining what feels like “Qwilr” is harder to articulate clearly in what we’re building.
Our first hurdle towards Undeniable Bestness was the consistency of our most basic UI building blocks, our colour use and buttons. As more engineers joined, more features were worked on, and more buttons were being rebuilt inconsistently, creating a compounding double up of work. It can be hard to argue the business value at this stage of the work, but we know consistency creates better expectations around how our product works, and it’s the difference between something feeling polished and patchwork.
I know what you’re thinking. Problems with consistency? Time spent on rebuilding? Scaling a growing team? Ahh of course, the answer is obvious. The solution to all of our past, present and future product scaling problems — a design system! Seems like everyone’s thinking about them, talking about them, making them, we just need one of those right? In part yes, as we’ve never had a centralised place with all our various code and design components for others to re-use easily. Our first step towards this was in design only, as a Sketch file hosted in Invision, which detailed all of the UI and states as a source of truth.
Initial goals
— make it easy to find during live projects
— make it clear what all the states of the UI are
— make it easy to inspect those details, so engineers have the values they need
Building a two sided system
Having the system in design helped clarify what our UI was intended to look like, but it was divorced from the reality of the development process. Having this system living purely in design meant it wasn’t integrated into the full product process, and taught us something important — we’re solving a much bigger problem than efficiency. We’re scaling our thinking and approach, well beyond just a UI library. We’re embodying our principles in the product and making them accessible for everyone working on it.
Revised goals focusing on clarity through collaboration
— make our core components consistent and up to date across Design and Engineering
— understand how principles are embodied in different practices(icons, tone, launches)
— in turn, make it easier to live by our principles in the product
Naming our design system
With these revised goals, it feels like a lot to try and encapsulate in a name, and as an aside, I am truly horrible at naming things. I have zero imagination for it, and every single cool or creative project name has always been born elsewhere. But, after chewing it over with the team, we’ve decided to call our design system Kaleidoscope — as our intent is to allow everyone building the product to contribute their small pieces, which in turn form a kind of magic for the user. All with ease, experimentation, and fun. We want to contain everything from how we generate ideas, to framing feature narratives, to the actual building blocks in code that make them.
Sharing as we learn
Over the coming months, we’ll be sharing what we learn as we’re building the Kaleidoscope, focusing on how Design and Engineering work together to create value for us and our users. From the broader engineering concepts of idea to code, practical solutions we’ve found along the way, and how we’re scaling this system for everyone.
It’s just the start, but we wanted to start this blog to highlight what I think is a unique benefit of working on the Qwilr product. Design and Engineering collaborating in a meaningful way throughout the process. Particularly as someone managing design, having a space for us to share openly and from multiple perspectives the struggle of marrying intent and execution, I think could be really valuable for others as well.
You can follow this publication by clicking here, or follow me on Twitter here. If you’re based in Sydney and want to chat design, systems, or startups, drop me a message and we can grab a coffee ☕️
️
