At HashiCorp, we practice versioning through codification, the belief that all processes should be written, versioned, and shared. And it’s not strictly an engineering mindset; our designers are doing it too. In that spirit, we’re sharing how we updated HashiCorp Consul’s Web UI (read the blog post for that release here).
The Consul Web UI has served its users well but has been due for an update. HashiCorp has been investing in UI development, creating modern design libraries with intuitive experiences for our other products and we wanted the Consul UI to also adopt the same visual language.
In this redesign, we have not added many new features. This was a deliberate choice, restricting new features only to those we deemed necessary. We wanted to improve what we have, and pave the way for more seamlessly adding features in the future.
Consul should be as consistent as possible with our other HashiCorp products. For folks who are used to our other products, Consul should feel familiar. This design consistency will also make our design operations more efficient. However, we took a pragmatic approach with consistency--we found unique opportunities within Consul to do things differently. Any inconsistencies are intentional, not accidental.
At HashiCorp, our users work with us. Our engineers are often folks that used our products at their previous employer. We’ve relied heavily on their input when designing our user experiences and visual designs because they know our user’s needs really well.
But, with this major change, we aimed to do user testing with external customers and get validation on our products before committing them to code. It’s a best practice, and we’re looking forward to doing so more often.
In the middle of our product development cycle, lives the the RFC (Request for Comments document), where engineers propose technical solutions to a product challenge. The purpose of an RFC is to express intent, gather feedback, and maintain a written history of product evolution. RFCs are a form of rubber ducking for engineers, offering a chance to double check assumptions and serve as a historical record for release authors or future engineers.
Product designers at HashiCorp participate in the RFC process by providing mockups and prototypes as needed. This project was a unique case in particular because the design was the focus of the RFC, not an addendum. So, we gathered feedback in three phases:
The RFC process spawned great discussions, fostered idea sharing, and gave us an outlet to document our design process while sticking to agile design methods. Writing the RFC document saved us a lot of time in the long run and ensured we’re on the right track (and the same track at that).
We sent out a survey on Twitter, Facebook, and LinkedIn about Consul UI usage. Over 110 people responded within a week, and 86% of those said they were willing to do user testing with us. We also gathered information about the range of scope across which Consul is being used.
More importantly for design, we received data on how people feel about our UI. Half of our users only use Consul in the browser as a last resort, or not at all.
We’d like to change that. If implemented well, a client interface for Consul will have great potential for handling service discovery and health checking. Not to mention the potential it has for some of the awesome, visually oriented features on our roadmap.
As our designs became clearer through the RFC process, so did our user testing plan. This project is our first “official” user testing at HashiCorp, and we hope to do more. We aimed for 4-6 participants from a variety of scope and sentiment. Here’s the makeup of participants we spoke with:
We learned a lot from our user tests.
For lists, we aimed for information density that still felt simple, and quick filtering that wasn’t an overwhelming amount of options.
In order to show a variety of Node health information, we went with a card layout. The goal again, was to show quite a bit of information without overwhelming the user, and give them the ability to simplify their views through quick, intuitive filter options.
We chose a primary magenta based on a few considerations: it needed to be dark enough to avoid soft pink but light enough to still be magenta--not purple. We also had to implement it in a way that didn’t compete too much with red, which is used throughout the tool to indicate failing status.
So, we chose Magenta 600 from our brand swatches as the primary web color, and used the same blue action color that we’ve employed in our other products.
We designed our status icons with color-blind users in mind. The set offers three affordances, or clues about what an object represents or how it can be used. Not only the color, but also the background shape and the icon itself all help to differentiate each status symbol, helping everyone easily scan dashboards for alerts.
Unlike table layouts, cards can show unique information for each item listed and can be optimized in interesting ways for easy scanning. Cards also provide more flexible space for each item than a classic table layout.
Our engineers implemented the redesigned styles for the Consul 1.1 release, where the visual update is available by opt-in. You’ll see this deprecation warning in the old UI.
For Consul 1.2, the new styles will be the default. And don’t forget--we’re always open to feedback on the Consul UI through Github issues. Thanks for reading!
The HashiCorp Consul ecosystem continues its growth with the addition of 13 new Consul integrations.
The new global management plane for Consul is now generally available. Try it out to gain full visibility for both self-managed and HCP Consul clusters.
Consul 1.15 simplifies user onboarding, enhances troubleshooting workflows, and reduces operational complexity.