Design systems are truly the near and immediate future of hands on, pragmatic UX/UI design. Leveraging them in your product is like disobeying the GPS and taking a strategic shortcut down an empty street instead of one filled with speed bump after speed bump.
Value in user centered design can come from many corners of the workbench of a good UX practitioner, but getting something into the hands of an actual user as quick as possible is the the real paramount point of value that a UX person can bring to a product, team, and organization.
Why is that? Because everything before this moment- all of the theorizing, brainstorming, and conceptualizing are just assumptions. None of it is truly valuable in the truest objective sense of having impact on customers and getting people to use your product until you actually get some demo-able version into their hands and seeing them use it.
I’ve battled back and forth in my professional career with wireframing and the tried and true method of incremental fidelity improvements in wireframing. It’s fool proof, I get it. Make a lofi design and spend only ten minutes on it, and test it. Learn from there that your assumptions are all wrong, and then spend the rest of your time making it right. Do this instead of making a hifi design and spending two weeks on it and testing and learning at that point.
Spend ten minutes coming to a conclusion instead of spending a week.
So where do Design Systems come in then? Well they allow you to bridge the gap between initial basic ideation and hifi design at a rapid pace. They are collections of components, styles, implications, ideas, and also act as a guide for consistency.
Using them allows you to jump to high fidelity designs and get to testing as soon as possible.
The practicality of hifi designs is that they allow your test users to see your product in an actual realized version. They get it all-the branding, the colors, the rounded buttons. They get to see the product and provide you valuable feedback on something that LOOKS and FEELS like a real product, and isn’t rife with placeholder images, confusing active/inactive states of elements, and a plethora of utterances during testing from you, the tester, like “sorry, that feature hasn’t been designed yet”. Using a design system is using placeholders that are actually high quality components and modular goodness and injecting it into your bad assumptions but meanwhile removing the psychological uncertainties of testing on what is essentially an amateur looking design.
THAT is valuable.
*Note: this case study is a proof of concept specifically to study a design system in depth. Because of that, there won't be extensive user research mentioned. To see my user research process, see some of my live product case studies here and here.
So what is "Soloist"?
Soloist is a product that I designed primarily to show these design system components in action. It's a SaaS that allows freelance educators- like music teachers, to manage their work. Scheduling lessons, adding and managing students, finding new students via social media marketing campaigns, and even receiving payment for services rendered.
I got the idea for this product after speaking with friends who are music teachers and learning that they had a few pain points with their current workflow in this space.
On the need for a separate calendar...
"I hate how my work calendar is tied into my google calendar. I want to be able to "clock out" everyday and not have to keep thinking about work."
"I'll be out to eat at a restaurant with my friends and we will plan upcoming events together, and when I look at my google calendar I'm instantly reminded that I have a busy day tomorrow and it starts to stress me out. My mind drifts to lesson plans when I should be thinking about what I'm going to order for dessert."
On the need for separate payment routes...
"Right now I can receive payments from Venmo, Zelle, Paypal, Cash, and I feel like a dozen more. It's annoying because I have to constantly keep track of so many different platforms. It makes tax time the worst."
"If something scooped up all of my payments and tracked them, like I could link accounts? That would be amazing."
With this info, I challenged myself to design a product in two weeks and return to these users.
Into the details...
I decided to use the Ant Design system for this project because I liked the idea of using an open source design system that had no extra paywalls or barriers to try out. I write all of my case studies with some kind of underlying message in them of "I made this with these resources and you can too". By using an open source system, this should make anyone trying to learn from this case study much easier to jump right in.
Using the base components and templates of Ant Design, I was able to quickly get a high fidelity, componentized design made, and ready to share with the same users who just shared their pain points with me two weeks prior.