Design System for desktop software

More than two years ago, I was asked to join a scrum team to help them build a new version of a software product as a first product in an all new software suite. All stakeholders where unanimous; the new application’s user experience should not be in any way like the current one. The new application had to be appealing and user-friendly to new users and still support experienced users with agility. But the most stated desire was a better support of the user’s workflow: all asked for more guidance and support through the workflow without losing their freedom in ways of work. 

Inventory of current state of rules and guidance

As I had never worked on a desktop application at this client before, I started to look for guidance in design and workflow. I started talking to managers, project leads, subject matter experts and developers. Quite quickly I learned that the desire for some guidance on what a desktop application should be like was a shared desire. And that there wasn’t much guidance on the design of desktop applications. The best I could dig up was an 3 year old document that stated some graphical specs on how to implement branding. The document wrote about Windows installers, CD covers and paper manuals, not in any direction of what I needed; the thoughts behind screen layout and workflow.

I also learned that users of the software loved and praised the current application by its accuracy and scientific base, but where less positive about its user interface. Some stated the desire to have the interface of competitor tooling and the results of our tool. Plenty room for improvement one could say.

Opportunity to set a new standard

This new assignment made me realize that this project could trigger the creation of a new standard for the desktop software. A kickstart of a design system could be a side product of this project. I had to come up with a strategy to convince my stakeholders as this would take some additional investment. The advantage I had with that was that the management already told me there was desire to rethink all applications in the geo context in the near future.

So I went down the line of cultural habits and wrote a proposal and presented it to some staff members to secure support for my plan. That didn’t go the way I hoped for, as I was told to incorporate the work in the project’s scope and budget. Clearly the time wasn’t right for a bold adventure like this. The staff was surely convinced of it’s importance, but budgets had to be allocated to other sources.

So I had to be creative and come up with a way of working that allowed me to do the research and design for the project, as well as the documentation needed for the design system. My solution was to do both in parallel during the project, which resulted in a slower pace in design results for the development team. But as scrum often comes with a tidal workload for research and design during a sprint, I could level the workload during the sprint. To make sure the design would be implemented as intended, the team held a no-feature, design focused sprint just before every release. This also helped to test and validate. To keep the team rolling in their own pace, I worked one or two sprints ahead of them. It’s important to understand that such an approach also asks a lot of flexibility and focus of the product owner and stakeholders while working on future sprints in parallel with the development cycle.

Contents of the design system

All research findings and design decisions made during the project that could possibly matter, where documented in a single resource while keeping the bigger scope in mind of the entire suite of products. The focus for the design system was therefore on strategy and communicating the thought behind the designs. Specifications on components would come later (if needed). My target audience at first would be another designer that would continue the work on another application within the suite. Later on that could switch to any other member of a project team. So what did I put in the resource first? I made an index after a brainstorm with some of my UX designer colleagues at ALTEN.

• Methods for research and design of new challenges.
• Rules for design. I based it on the 10 usability heuristics of Nielsen.
• General design values for page layout, type, color, contrast and communication with the user. Not technical specs (like pixel measurements), but descriptive values to share the thoughts behind them.
• Branding elements and resources.
• Specification of components on how and when (not) to use.

As this design system is created for one of my clients as consultant, I can’t go into the verry details of its contents, but I’ll guess you’ll get the point.

Evangelise the word

The creating or building of a design system itself is not that hard; you just have to combine the desired information into a single source. It’s just a lot of work that takes a fierce persistence and discipline. But then there is a source that you would like other to use for their projects, how do you convince them to do so? I started to link the project’s result to the design system. As the company quickly got notice of the project’s results, I started evangelizing the design system to anyone that might be interested. Any event like an department or unit meeting, I embraced as an opportunity to tell colleagues about my work on the design system and how it would help them doing theirs. Again I never spoke about pixels or RGB values as I just wanted them to think about the design rules and concepts related to their own projects. I expected them to come for specs naturally if they would validate their projects to the general design rules.

Future strategy

Unlike the document with CD covers I could dig up, this design system should not die in some lonely folder on a network share. The minor guarantee I had, was my own usage of the design system as long as I would be involved at the client as an consultant. Therefore I managed to have a UX-minded colleague to start up a UX knowledge group to grow the support and knowledge of UX within the organization. Inside that group I made the design system and it’s governance a returning topic. The group took over governance of the design system and it’s viability.

Current state of the system

At the end of the host project, I had a lot of work put into the document and resources in Adobe XD, but still no official state of it by the organization. Again I went to talk to managers and yet no success. 

But another project was emerging into the same software suite, so that new project became my new target to get the system in. As another UX colleague from ALTEN was planned to work on that project, I wend to evangelize my work (as far as needed) to the project leader/product owner. That project would be the first serious test to see if my document was effective or not. 

Later on it would show that the document still needed a lot of work, based on the questions of my colleague and the project team. The design system worked perfectly for the project it was setup for, but to apply it to another project efficiently, work had to be done.

Currently a project is being setup to get the design system ready for the whole organization. When funds are provided, a team of researchers and designers will make sure the design system is future ready for all coming projects. In the mean time I try to be involved in any software development project to evangelize the design system way of work.

Thoughts on creating your own design system

Are you planning to create your own (low) budget design system for your company or team? Let me share some findings of which I liked to had when I started this adventure:

• Start small and stay small. It sounds easy, but it’s really hard to keep your design system in scope. So best you get help from a project leader or sponsor that keeps track of progress and scope.
• Create a group of evangelists to build support from within the company. Don’t just ask the easy ones, use the ones that show most resistance as experts of pain in product or process.
• Talk to management and other stakeholders early and often. They get a lot to process, so keep reminding them of the importance of your work. Best to have your evangelists do that as well. As you are disrupting changing the development team’s workflow, planning issues are likely to occur quickly. Close monitoring and open communication keeps all stakeholders engaged. Make sure they understand the effects of the design system on their products, particularly in future developments.
• Find out what the development teams need first and need most before disrupting their workflow. Make sure you have something to offer: implementing a design system is mostly a behavioral change for all stakeholders, so treat it like that.
• Make sure you build the design system based on real content and components. Don’t assume you can build a design system in advance without a project that is using it. The design system is not a goal on itself, the improved user experience, brand consistency and aid for development and design certainly is.
• Don’t let technology be an advisor. There are plenty publications on the web on how to set up design systems and what technology or services to use. It’s like design tools: pick a tool that make you feel comfy and in control. My weapon of choice was simply  a combination of Adobe XD and a Microsoft Word file shared via OneDrive as anyone could read and contribute to it.

Would like to know more about setting up a design system or on how to incorporate it in your development processes? Let’s have talk over some good coffee. Feel free to contact me.