Last week I wrote about how the design team I lead at Discourse used design driven development to create our newest theme, Horizon.

Check it out here if you missed it.

What makes Horizon different

While many items make up the bulk of the Horizon theme, the three in particular that really set it apart are the Topic List Item, Welcome Banner, and Color Palette and selector. While Charlie and the design team continued to iterate on new areas of the theme, engineers from our member experience team and I worked to implement these components in parallel.

Topic List Item

The topic list item is one of the major elements we designed for the Horizon theme. It is different in many ways from the default topic list item from Discourse. Our goal was to simplify the amount of information on the cards, as well as clarify & highlight only the most important bits of information such as: author, reply count, last poster, time of last interaction, category, and if the topic is considered “Hot” with activity.

Before

After

Welcome Banner

While a search banner has always been available for an admin to install onto their site, we decided to make the process easier by porting this popular theme component into the product itself; no longer requiring an admin to know the ins and outs of theme / component installation.

Color Palette and Selection

We built a color system from a set of base colors using the oklch()system. Instead of needing to create a customized css stylesheet, defining which items/areas you wanted to set colors to, a user can now choose just one color to change their entire visual experience. An adorable easter egg we added to this theme were the names of the color options. Clover, Marigold, Royal, Violet, Lily are all names associated with kids of Discourse teammates! In order to have all color names covered, we’ve all signed an agreement that the next child born to a Discourse employee must be named Horizon.

The Maintainability Constraint

While I’ve been primarily speaking about the product and design motivations for the Horizon theme, other factors were also at play.

Opinionated decisions

From the outset, we knew Horizon would be a bit of a departure from other themes, which are built with further customizations in mind. Since we were building Horizon for non-technical admins, though, we wanted to be more opinionated to make sure it was a great out-of-the-box experience.

This meant that the theme would not support most third party components or plugins.This is a decision we still feel strongly about. By keeping the theme scoped to our original vision, we gave ourselves the necessary space to work without the usual constraints. We believe this ultimately led to a better outcome.

We were ok with this because opening up the ability to push this theme further than we intended with customizations would have damaged the overall outcome of Horizon.

Dual purpose

While the Horizon theme was the obvious outcome of our work, we also had our eyes peeled for ways we could make it easier for anyone who wanted to create a Discourse theme. When we found it difficult to customize certain aspects of Discourse, we cleaned the markup and implemented css variables into those areas to help future developers and theme creators to customize the same area.

Minimizing debt

We worked with engineers on our Developer Experience team to make sure that our additions / changes were not something that would increase technical debt over time. This meant trying our best to utilize tools already built into Discourse that allow us to customize / replace existing elements in a safe and secure way. A small example is how we built Horizon’s topic list item component here.

Testing it all out

We tested out our theme in three primary ways:

• Our internal work community (Dev)
• Our support forum (Meta)
• Select customer site beta testing

The internal and community forums we use for work have 12+ years of discussions built up on them with 100s of users. Testing the theme out on these instances validated a lot of our decisions. These communities gave us many different forms of content to battle test all of the elements of our theme. We were able to get ahead of a large amount of visual and functional issues before a public release using this method, adding polish with every iteration and fix.

After dogfooding the theme for ourselves, we moved onto beta testing. We identified customers who matched the personas we had in mind when designing Horizon. This led us to install the theme for a handful of different communities where we received feedback from both their users, and the administrators who run the forums.

Not all of the users (both internally and externally) who tested Horizon particularly enjoyed some of the opinionated decisions we made. We filtered feedback through our personas to help us decide whether it would make the design work better for our non-technical admin and everyday members.

Key takeaways

Designing out in the open

Our weekly design meetings to discuss and critique the progress of the Horizon theme were summarized and posted publicly to our internal forum each week. This allowed those outside of the design team to see the depth, detail, and iteration we were working toward. This was a great way to spread the influence of design thinking and process through the team. Inviting public discussion helped the design team build trust with other team members as they saw their feedback and ideas incorporated into the project.

Back to the drawing board

Testing with users uncovers needs that you can't always anticipate in design sessions. One key insight was re-thinking decisions we made in our topic list item. We felt strongly that the avatar shown on the card should be the original poster, not the most recent replier. While we still went with this choice, feedback started to roll in that people wanted to also see who replied or commented last as well. This caused us to go back to the drawing board and tweak the positioning of topic list item elements in order to accommodate for that.

Centralized partnership

This structure worked very well for us on the project. Charlie was the main designer who “owned” the Horizon theme as part of the member experience team, but this did not stop her from getting input from the entire design team. Other designers, along with engineers were also able work together on owning implementation of sub elements of the theme. It was an extremely refreshing way to work with one another and something I’d love to see more of in the future.

What's next?

Horizon is now the default theme installed when you start up a new Discourse instance.

There are more projects where we’d like to utilize these design driven processes again to tackle in the future:

• New themes available in Discourse
• Exploring category and spaces setups
• Admin and New user onboarding

The success of Horizon proves that design-driven development can be used at historically engineering-led companies. Clearly defined personas and principles, free-flowing feedback, and a commitment to user needs have the ability to lead to undeniable results.

The above piece is a part of a larger blog post I wrote for Discourse. You can find the original piece here.