Crafting a UI from Scratch



UX Designer @ Shinydocs


Matt Ellig (Front-end Team Lead)
Babalakin Oyewumi (Front-End Developer)
Becca Ellig (Marketing Specialist)


Adobe XD


Slide decks
Design system with 200+ interactive components and variants


When I joined Shinydocs their flagship product didn't have a UI. It was just a command line tool. This project is the process I went through to build a design system from scratch.


No Front-End. Period.

At the time of joining Shinydocs, the main product that we were selling to customers was a CLI tool. Yes, a command line interface. No UI whatsoever on our main product. We needed to define a visual design language that would be used throughout our products to create a consistent look and feel that would align with modern design standards, including accessibility.

No Usability

Users of our product were required to copy and paste command lines into a terminal window in order to accomplish any task.

No Visual Design Language

The only semblance of branding anywhere on our product was on a white-labeled version of some other company's software.

Accessibility Challenges

Switching between different windows, copying codes, and lack of visual feedback created fairly large accessibility problems.


A UI Component Library

Creating an accessible, universal design system would allow us to provide a meaningful user experience for our customers. The value from building a GUI into our products was almost immeasurable and would allow us to wildly expand our market reach.


Aligning with the Front-End Team

To their credit, the front-end team had recognized the need for a standardized UI library and had begun work on the foundations. They were lacking in experience related to both UX and UI capabilities and needed my help in fleshing out the library completely and providing a strong lead for where to take what they had started to the next level.

What we needed as a team in order to complete this work successfully:

Clean Hand-Off

I built an easy to navigate design file with notes and implementation instructions for each component.

Brand Guidelines

I visited with the Marketing team and discovered that we didn't have a very strong vision for the Shinydocs brand.

Color Definitions

First draft at defining the color language that we wanted to use throughout the UI. This later turned into a more robust document, as highlighted later in this case study.


Difficulties Along the Way

Aligning with Stakeholders

Meetings were set up with internal stakeholders in order to get alignment on where we wanted to take our products. One exercise I led was dot voting on different moodboards.


A huge focus was meeting WCAG 2.1 AA standards. Even just finding the right green for our primary buttons proved to be an interesting challenge. 

Demand for Definitions

There were cases where I wasn't able to touch every design on every product and in those cases the front-end team wanted more robust definitions of the colors that we were using, with use-cases for each.


A Completely New Look and Feel for All Shinydocs Products

Together with the front-end team we created a Storybook library of design guidelines, an expansive list of color definitions, and over 200+ individual components and variants for both light and dark modes. This component system is being implemented across all of Shinydocs' products in order to provide a cohesive, high-quality, branded experience for our users.

The final deliverable for this project is a Storybook component system. All components have multiple variations and write-ups that define their use cases, accessibility considerations, and purpose.


Lessons Learned

Being able to work on a design system like this from scratch was a unique opportunity that I don't think a lot of designers get, so I am grateful that I was able to have this experience.

  • Working with others can bring out the best ideas. From marketing, front-end designers, VP's, sales. There are ideas all around. It is sort of double-edge sword since literally everyone you talk to is going to have some sort of opinion on the design of the product, but being able to bounce ideas off others more often than not allows the best ideas to float to the top. I reach out to others regularly to explore ideas and make sure that my designs are ideal.

  • Accessibility is top of mind. Working on this project cemented the importance of making sure that designs and interactions are accessible. There is a movement where more and more software is moving towards to being usable by an increasing number of people, and as a designer I want to make sure I am part of that movement. Working extremely closely with the front-end team also allowed me to gain a deeper understanding of what goes into actually building accessible components.

  • Design systems are a ton of work. This project was another reminder of how much work goes into building an effective design system. We continue to tweak and add to the system to this day and it is always improving. The benefit is that we are able to build much quicker and with a higher degree of accuracy because we have solid building blocks to start with.