Going deep in design

We hit two challenges when using the low fidelity approach from Shape Up:

• Too tight for deep design thinking. In Shape Up designers create the final designs at the same time as the engineers build the solution. We prefer a lead time that allows us to iterate on the design with less engineering rework. For V3.0 of Joyous we also needed more time to create our new design language and design system.
• Complexity isn't obvious. Our engineers missed something big when doing the technical shaping from fat-marker sketches and breadboards. Yet the moment they saw the final designs and prototype, it was completely obvious to them. We landed in a situation where we were making big decisions mid build. We handled it well and made a good decision fast, but we wanted to avoid that in future.

So, now we go deep in design ahead of a build. And collaborate heaps during this process. We ensure there is a clear path for the work to be done as efficiently as possible at build time, without being held up by design.

When it comes to our design language we don't try to reinvent the wheel. Instead we use Material Design and customise it to our brand.

We use Figma as our design tool. Inside of Figma we have a defined structure for our design system, projects and files.

Our design system

We follow the Atomic design methodology. Before build time we ensure our designs are accessible. Our designs conform to Level AA of the Web Content Accessibility Guidelines (WCAG) 2.

Figure 13 The Joyful Design System - Atomic Design Pages

This version of Joyous involves a full UI overhaul. So we have created a new design system as part of this project.

We build components with a 1-1 mapping to engineering components and use Figma Variants for different styles and states.

Figure 14 Atoms with variants inside our design system.

Our Figma project structure

• We create a project in Figma (in this case for Joyous V3.0)
• We created a 1-1 mapping between the project Figma files and the project chunks.
• We use the same file names across Notion (on the Joy Board) and Figma.
• We include in the titles the status of the file [❣️not started], [💛 in progress], [💚 ready]

Figure 15 - Our V3.0 Project Structure

Our Figma file structure

For most of our chunks we will frame up the features in Figma. We mean this quite literally. We have a Figma File Design Template which is the starting point for each chunk.

Figure 16 Our Design File Template

We create a Work in Progress (WIP) page in each file. Within the page there are two swim lanes. The top lane contains a series of frames defining the first release features. The bottom lane contains a series of frames defining the features that can wait.

Each frame has a feature name. We will map out all the frames before we begin to do the visual designs. This is what we mean by framing the feature.

At the end of each lane we will show final composed desktop and mobile views. We create another page in which we build a prototype demonstrating the UX of all the features (now so much easier to do using Figma Flows).

Figure 17 The lanes of the Insights chunk

For each major revision we will create a new WIP page, and rename the previous WIP page with a version number. Once we reach a point of readiness we will create a For Dev page into which we place the final frames ready for review.