Wonder is a new solution to video conferencing that allows large groups to meet online in a way that is more organic and free. Wonder's spatial UI enables participants to escape the rigidity of the video grid system found in applications such as Google Meet and Zoom. I was part of the founding team and worked to bring the product from a small audience to a post-market fit stage. During this period, I was a principal designer and oversaw different aspects of the product experience, such as product strategy, design execution, and design hiring.
After completing the brand guidelines and product narrative, we had a clear path of where to take the product and well-thought-out brand guidelines. But to have a substantial product impact, we needed a design system that helped product managers, engineers, designers, and researchers to have one shared vision of how design problems should be solved. The combination of micro-interactions, information architecture, motion, icons, and look and feel all helped to make Wonder's mission of bringing people together in ways that feel more natural a reality.
After leading the design and execution of our new branding system, I led a team of two designers through the evaluation, experimentation, design, and validation of a fully-fledged design system that considered the end-to-end product experience. The result allowed us to speed up product execution and elevate the product experience.
A design system is a set of tools and resources that help the team confidently make decisions. Design systems help bring consistency to the product experience by elevating the user experience and increasing the speed and efficiency of designing and building products. They are a source of truth and a system of record for our design decisions while also helping to protect the brand. Sound design systems often go beyond the rules to also include the why, when, where, and how.
Instead of setting ourselves to build an extensive design system at first, I focused on delivering the equivalent of the minimum viable design system that allowed the project to gain traction in the team. Because of the high cost of developing a design system, from visual design to engineering, I wanted to keep the project scope in line with product outcomes and wider company goals. It's always easier to expand on a design system once the value it produces across an organization is clear to all produsct stakeholders.
We turned the insights we gathered about the product experience into four principles to help guide our design explorations. These principles were built bottom-up and included the whole product team's input and considerations. We used these principles to clarify the gap between the present and future experience we wanted to create.
Aside from principles and high-level design guidance, we broke down the end-to-end experience into small building blocks. We wanted to first start with the smallest blocks, use these small bits, and then assemble more complex components.
Design tokens are all the values needed to construct and maintain a design system – spacing, color, typography, object styles, animation, etc. – represented as data. These can mean anything defined by design: color as an RGB value, opacity as a number, and animation ease as Bezier coordinates. They're used in place of hard-coded values to ensure flexibility and unity across all product experiences.
We wanted to build a design system based on design tokens. Using tool-agnostic tokens as shorthand, we can be consistent across tools and teams and present consistent rules to UX designers, UI designers, and developers alike.
Once we had a solid base, we began by doing small design experiments to allow us to understand and test how simple rules could be put together to build a more complex set of elements. Every designer created a proto-design system to generate a wide range of options. Our goal was to use simple rules and elements to build more complex components and layouts to see how they behaved. For example, I made experiments that focused on communication (Website) as well as heavy UI work (Meeting Experience). I explored color contrast, spacing, layout, tone of voice, and typographic hierarchy across many elements.
We showed these experiments to the team and presented them to users to validate usability, contract, and look and feel. From the experimentations of all three designers and the feedback we received from the team, we created a final system of building blocks we could begin in a short time frame.
In the context of a startup, even a simple design system can be challenging to pass and gain adoption. But we balanced the need for immediate results by focusing on simple building blocks rather than a fully-fledged comprehensive list of components. But this came with a caveat: due to the lack of components, our original set of building blocks was still used rather loosely by designers in the team. In retrospect, I would have liked to dedicate more time to working with the designers to build these components in the earlier phase rather than relying solely on documentation.