Building a Design System from Scratch
Disclaimer: Any designs featured here are recreated with all project-specific information removed
The Problem
I collaborated with a senior designer to help a team unify their brand identity across different tools – one being a custom-built application to collect data and the other being dashboards built within the Qlik software that would display the collected data. We offered improvements in the user interfaces and task flows using these tools.
Both of us joined this team at the same time and had to hit the ground running immediately since this design project had a limited time frame. We knew we needed to fill in the gaps of our knowledge so we spent a bit of time getting demos of the tools we would be redesigning and learning more about the team’s history.
From poking around in the tools ourselves, we soon discovered the different styles both within and across the tools. So the first starting point was to consolidate the fonts, colors, branding, etc. used and establish a cohesive visual language across them both. We worked on different parts of this brand guide – I worked on a component guide where I tracked all components used within the tools and included best practices and recommended use cases. This was important to work on in order to establish standards but I found it extremely helpful for gaining more familiarity with the tools I was working with. This was my first time creating a component guide, so I referenced existing guides out there (like this) to create one specifically for this team’s design system.
I would break down each component using these sections:
- Overview: brief explanation of what the component is and examples of where they could currently be found within the tools
- Usage: how the component should be used
- Best Practices: these are standard practices to implement this component
- Recommendations: suggested ways on how this component should be use
- Include screenshots and locations of the component in action
- This is helpful for developers to reference if they know they need to work on a specific component and to know where they would need to check/test
Now that we had more context on the project and developed a pretty good understanding of the tools’ interfaces, it was time to work on talking to the users themselves to understand what was working well and what could be improved upon.
User Interviews
While I was working on coming up with user interview questions, I found myself struggling to narrow down what questions I wanted to ask. My lead helped me to realize that before even figuring out the questions, we had to determine what the end goal was – we needed to understand what we were delivering and what info did we need to deliver first. For example, some ideas we had were a way to organize data for their tools and a way to simplify their common task flows. If we wanted to improve how they organize data then we would need to ask about the current data collection process, why they do it that way, and if there are any requirements or clients driving this data collection.
Once we picked an end goal, the questions that we needed to ask in order to fulfill this goal became very clear.
I had never led a user interview before or ever been so involved with user research so I felt a little bit awkward conducting the interviews – also doesn’t help being someone that isn’t the best at speaking in a professional setting lol. But I did it and I’m proud!! Because we were interviewing people on the team (and not actual clients), it was less formal and I was able to be more at ease. (Though I was still sweating every time I had to do them). One thing I learned was to not really treat it so much like a formal interview but rather a flowing conversation. It was okay to not hit every question that we had and to adjust what we ask to the person we were talking to. I also made a mistake of asking a leading question so yeah definitely don’t do that lol.
The next step after the interviews was to synthesize the information we got in order to better understand the pain points and develop solutions for them. We organized the information we got from the interviews into a spreadsheet starting from quotes/notes from the interviews, summarizing them into a finding, which would then allow us to form a recommendation. Organizing it this way helped me to present our findings from these interviews to the rest of the team. For each process flow there was, I noted the pain points and success areas from the interviews, and then followed up with recommendations. For how this looked like in action, there was a process for entering data into a system that could only be explained and demonstrated by certain team members. Part of the problem here was that there was a specific order to how you had to enter the data and you had to access multiple pages to do it. It was not apparent to a new user what you had to do. It’s like if all you needed to do was shake the hand of another person but they tell you that you need to do this convoluted, secret handshake instead. Like we’re just trying to enter data in here, not memorize a trick for the circus. So an opportunity for improvement here would be to streamline the whole process from start-to-finish on one page instead of multiple and only be able to complete one step at a time – kind of like a multi-step form.
(Will also note that each area of improvement should be prioritized, we ranked it based on what we thought was high priority and would be the most impactful change and presented this to the team to make sure we were on the same page.)
Prototyping
Now that we identified and prioritized the areas of improvement, it was time to create prototypes of our solutions. Even though I usually love wireframing and building prototypes, it was especially difficult for me this time around. I had a bad case of fearing the “blank canvas”. I didn’t have a single clue where to start and I felt like I had to understand the full picture before I created a design. But I was putting too much pressure on myself – I knew I still had gaps in knowledge of the tools and that the project leads had difficulty expressing exactly what they wanted. So really, we could only do the best we could with what we were given and that was the reality. Once I let myself be okay with that, I became more productive and was able to produce more designs – some good and some bad. What also helped break my creative block was looking at good examples. I am a baby designer so I still need to train my eye a lot on what is considered good design – in this case, something that looks professional and modern, while being able to be implemented in Qlik. So going on Dribbble, researching Qlik dashboards, and looking at what other people have built was really helpful to me. You never know, the solution may exist out there just in a different way.
My process to creating designs
- Think about the overall objective: What are you trying to achieve with this design?
- What features are required? Are there any that are missing?
- What existing standards can be applied? (e.g. if you’re including a form element, then apply form standard practices)
- Communicate a story: Not only do you need to explain your design decisions, you also have to be able to showcase how this applies to a real world use case (i.e. through user stories); this part typically comes later in the design process but I can see this helping to inform design decisions too!
- Other tips
- Aim to streamline and simplify
- Improve labels and add icons for help when needed
- Don’t forget to add error handling!
- Aspect Ratio
- I realized my designs were not reflective of what the actual size would look like when implemented. So in development, things looked a lot wider. Noting the aspect ratio is really important because things can look differently when the design is implemented.
During this phase, I ended up redesigning many existing dashboards using this exact design process and keeping those above tips in mind. Eventually I got into a pretty good flow starting out with low fidelity mocks and drafting requirements for each redesign. These requirements include defining the objective, user stories, guiding objective questions (related to the objective but these are big picture questions that we aim to answer), guiding process questions (what we aim to answer in terms of what tasks the user wants to do), and data/visualization/style requirements (this is what the developer would reference in terms of what colors and data sources to use in the implementation).
Design Feedback Sessions
So you have your prototype and now it’s time to get feedback on it. The thing about design is everyone has an opinion on it. That’s probably a quote someone’s said once. In fact, this was one of the more difficult parts of doing design work. It’s interesting that many non-designers seem to have strong opinions on design but as a developer, I’ve never seen non-devs question how or why devs implement something in a certain way.
So what to do?
Here are some of the things I learned on how to receive feedback on your designs:
- If you’re too general, people may not give you the helpful feedback you need.
- Instead, I make it my goal in design feedback sessions to stay focused on getting answers to my own questions. And of course, if there is anything that is important to include in the design, that should be discussed. But also figuring out priorities in designs should really be done in the early stages of prototyping, not after it’s finished.
- This is helpful for keeping meetings on-topic. It’s great if the people in the meeting have suggestions that are not high-priority, but it can be given outside of the meeting.
- In the sea of opinions, the objective statement is the guiding light. What data is necessary here and supports the objective? Subjectivity doesn’t get us anywhere so I learned the importance of picking out what design choices are backed by the data. It helped to frequently ask “why” and refer back to the agreed upon objective.
- Balance technical feasibility and creativity
- A lot of my work involved redesign so I looked at the original design and assessed what was working and what was not. My project leads wanted a brand new, fresh design whereas my team members that worked closely with the tool were accustomed to similarities and liked keeping certain design choices. It was a balance of opinions and what was technically feasible. I played around in Qlik and tried to recreate some of my designs to see how much I could push it as a tool. It also helped to consult an experience Qlik developer to validate my thoughts too.
- Side note: I’m not sure why but the workplace has never felt like a creative place for me. I just do what’s needed and don’t often push for anything extra. (Hey, we’re all trying to survive here.) So when I’m told to “go wild” and design something….I was super confused. Surely you can give me more direction than that.
But in the end, the reality of it is: not everyone is going to like what you design. What is important is that the key decision makers approve of it. That makes me uncomfortable to say but that’s the truth. Anyway, life as a corporate designer amirite?
Lessons Learned
Overall, this was such a valuable experience for me as someone that was always interested in doing more design work but felt a little intimidated to try. After going through this experience, I have even more respect for designers and unfortunately, did confirm my own fears about design work. At the same time, I felt proud of challenging myself to work in such a capacity. I went from writing code every day and occasionally doing demos of my work to having meetings every other day, presenting my designs regularly, and having to write using business-oriented language.
One lesson I learned was that if nothing is clear and you feel confused, it’s NOT YOU. It’s bad communication and it’s the result of a chaotic environment. But the work still has to be done regardless. I felt very confused a lot of the time working as a designer because I wasn’t able to elicit clear requirements from leadership. It was only by observing how a more senior designer handled the situation did I understand what I could do to create more clarity and structure for myself, but also acknowledging there are limitations that we have to accept. If we aren’t told clearly what we’re supposed to deliver or what our clients want, it’s hard to make something that will be useful to them. It’s hard to do our jobs well. And that’s something I had to accept. Sometimes I didn’t feel that great about my designs because I just struggled with getting clear answers about literally anything. I do, however, feel proud knowing I did the best I could in the environment I was in, and I won’t be harsh on myself for the quality of my work.
In hindsight, the approach of understanding the context behind the work and doing the work at the same time resulted in a lot of extra work on our part to revise and adjust to new pieces of information. It was exhausting and stressful because I felt like nothing I made was right. I was essentially guessing based on what I knew and the info we had gathered so far. But we still really only saw a very small piece of a project that spanned across many years. That’s why, while I understand it’s part of the nature of consulting to bring people on for a short period of time to accomplish a specific task, people can’t do their best work unless you fully incorporate them into the team OR someone that knows the context works closely with you on your work.
Another lesson I learned was that team unity starts from clarity. If everyone understands the purpose of their work and they are able to succinctly explain it, then that’s a team that will operate with purpose and efficiency. But if everyone has a different idea of the purpose of their work, then there’s bound to be miscommunication and challenges around that. That’s why I learned, it’s good to establish an elevator pitch for their work. If you’re building a tool, decide on an elevator pitch for that tool. That way there’s no confusion. This is what I learned during the user interview process from my design lead. She asked great questions around having an elevator pitch and what role each interviewee saw themselves playing in contributing to that elevator pitch. If the tool’s purpose is to simplify a data collecting process, how would they contribute to that? Maybe they teach how to use the tool. Maybe they are the ones doing the data collection. And once there is this clarity, it’s a trickle-down effect. What we have to accomplish through design will be more apparent.
The biggest thing that surprised me about being a designer was I had to think about business requirements and be able to explain the value of my work often. Having to constantly justify every single choice and for others not being able to see the immediate benefits/impact was tiring. As a dev, the work that I would need to do is already decided and I have a clear end product produced from my work. But with design, it feels like you have to constantly push for your design to be built the way you intended it to be built. It’s like your designs are just a suggestion to a dev. I’ve never felt this way as a dev but I can now totally understand how helpless one can feel when you don’t have control over the end product. But one good thing about having experience as a dev is if a dev does try to tell me they can’t implement something in my design, I can literally fact check them with a, “no, I just wrote it and tested it out, so you totally can do it too.”
On the flip side, I keep devs in mind when I create a design. I try to send over any design specifications that would be helpful for development and I always think about technical feasibility.
And lastly, probably the most important lesson I learned was: Be confident in your work! You thought your designs through and you should be proud of them. I struggled so hard to be confident in my own work, and even as a developer I still face impostor syndrome. But I take pride in that I always aim to do the best I can, and through my writing, I try to pay that respect to everything that I accomplished. Even if it was hard or didn’t really leave the best memories for me.
Similarly, I hope that other designers in their early stages like me don’t falter or lose faith in their own work. Keep on going and believing in your work. Nothing beats a jet2 holiday, except a human designer.