Hitpaw Design System

We started by sorting through the main problems in the product interfaces we already had. Building the design system needed design, engineering, and product managers working together, so we wrote a 40-page brief on what the system is for, how it is structured, and what each stage should deliver.

I made the case for the system from three angles:

1. A consistent product experience
2. Faster design and collaboration
3. Lower development cost

The brief got the product team to agree the system was worth doing. The cost was still high, and the short-term return was hard to measure, so it could only move slowly, with resources won a step at a time. That was about what we expected. Along the way the business lead and the boss backed it, in person and by email.

Once the need for the system was agreed, we started building it.

Color came first, and it was the hardest part. From the brand color rules we built a functional ramp for desktop products. The brand color is hard to read in dark areas, so we rewrote how it is applied there. After comparing the main products on the market, we made two palettes for background and text that still fit the brand, and swapped only those colors into the interface so we could compare before and after.

I also walked the design team through how to use the component library, how to choose when one product conflicts with it, the rules for adding to the library later, and what “consistency” means on this project.

We also settled on three design principles:

1. Perceivable — the important information reads clearly
2. Short steps — fewer actions to get through a task
3. Guided focus — help people stay on the task that matters

With the principles in place, we built the library in layers: atoms, then molecules, then organisms.

• Atoms: type, color, shadow, spacing, stroke, and corner radius
• Molecules: buttons, radio buttons, checkboxes, dropdowns, text fields, and steppers
• Organisms: reusable pieces built from those molecules, such as alert dialogs, the upgrade module, the sign-up module, the trial dialog, toasts, the About page, and the splash screen

To keep some character in the product, we also redrew the little black cat mascot so it could sit inside the interface.

Once the usual design-system pieces were in place, we added what desktop software needs on its own. A button has five states: default, focus, hover, pressed, and disabled. A window also gets a default size that follows the user’s screen resolution.

Following the way Microsoft annotates specs, we marked the usage and the state rules for every component, so the next designer could pick the work up in order.

That finished the design of design system v1.0, and we started putting it into the product. We looked at Tencent’s design tokens, but the software is built in Qt as a cross-platform app, so their logic did not fit. After working through it with engineering, we wrote a Design Token naming scheme that works in Qt.

The first version mostly ends here. The hardest part was not the design. The library and the tokens are regular work, plus the extra pieces shaped by how desktop software works.

Two things were the real challenge for me:

While building it, I found the library was too basic to steer the design direction of a whole product. Skill on the team also varied, so ideas that were too complicated did not survive contact with the work. Many people were already stretched assembling pages from preset components, let alone using a deeper system. That is why the principles I finally wrote down only kept the three points that mattered most.

Work is never finished in one stroke, and collaboration even less so. On this project we could only move one step at a time as the team got stronger.

The project ran long because everyone’s time had to line up, and the resources had to arrive. The business also moved fast. Halfway through I realized the future is usually not predictable. A lot of what we had designed created new problems as the products iterated, and the product plan was unlikely to follow what I had imagined. I dropped the idea of a design system that covers everything, and switched to solving the problems we have now. That is the biggest thing I took from the project.

When we design components, consistency is usually the first thing we reach for. As designers we can even ignore the user in order to keep things consistent, and spend more attention on administration and upkeep. That works against a system that is supposed to center on people.

Consistency is still the right idea. We pursued it at the start so we could work faster. Chasing it blindly does the opposite, and it drifts away from how the product is actually used.

So when we design for consistency, the point is not building and maintaining the pieces of the interface. It is solving problems and helping the user. Design systems and component libraries have been a bit mythologized in this field. As a tool for cutting cost and raising output, they work. When they become the first rule you have to follow, they work against you.