If you're interested in a more technical look at Lodestone, check out Peter's articles. If you want, support the project here!

Lodestone started as a hobby project between frustrated college friends. If you just want a small shared Minecraft world, you have to either

• Spend hours learning about networking and technical jargon, or
• Spend money on a terrible SASS dashboard designed to rip off 10-year-olds

Why wasn't there software that was high quality, open source, and accessible to all? Something built by the community, and for the community?

We decided that we'd create that future with Lodestone.

Stumbling along the way

Working with such a small team presented some interesting challenges. UI Designers are typically approached with a design brief and a technical spec sheet to work off of. But Lodestone was a collective effort. I had as much weight on the system architecture as engineers. If anything was going to get done, we'd have to do it together.

Our starting design system for Lodestone looked like this: ...a set of primitives including colors and fonts that made up our prototype landing page. Here's a comparison of what our first dashboard prototypes looked like, compared to the final product in production today: ...but in between the left and right was a lot of stumbling along the way. If I had to give younger Wilbur some advice, here's what I would say.

1. Don't get tied in your own web

One of the best things I did during the design process of Compass was to actually stop using it. At the end of the day, Design Systems are tools to help you, not tie you down. I treated the system as absolute, limiting my creative output. Once I broke out, it was like a breath of fresh air as I once again had infinite colors and variants to play with.

My new workflow begins in a file aptly titled "Playground," where I allow myself to tinker without any restrictions. Once I notice designs approaching a consensus, I tie it back to Compass and create new components where needed. This has led me to create UI that better matches our needs, and a much faster rate. To do real, productive design, things need to get messy. Resisting that will only hurt your creativity.

2. It's good to take a step back (literally)

Lodestone unexpectedly taught me a lot about typography, and one of the most valuable was design at 100% zoom! Figma has the handy feature of allowing you to design zoomed-in, but that can easily skew the sizes of your layouts if you're not aware of it. It was only halfway through creating Compass that I realized that our font sizes were unreadable at default scaling, and by then our developers resorted to using completely different font sizes in implementation. Refactoring Compass and our Tailwind Configs that night was both daunting and extremely satisfying.

3. Your designs are only as good as your references

References when drawing are extremely important, and the same thing applies to web design! I started without looking at any design systems, and it shows in the initial prototypes. Do your research, and look up great libraries to see what other designers have done. For anyone looking for resources, I recommend these:

• Shopify's Polaris has great documentation on design patterns and principles.
• Figma's Design Systems publication has fantastic writing on DSL architecture and philosophy
• Linear's app is an incredibly polished modern dashboard, and there's a lot to learn just by exploring it.
• Butterick's Practical Typography has all you need to know about fonts and words.

Once you're consciously looking for references, you'll realize that great design hides in every nook and cranny of software.

The final product

Compass currently contains a set of around 50 styles and over 50 components split over colors, buttons, labels and more. If you want to see the whole library, check out the Figma file.