B

close
ThreatQ Dashboards

Crash Kit – ThreatQ’s Design System

During our company off-site in February, I had the honor of presenting how far our design team has come. We’d more than doubled our UX research efforts, delivered the designs needed to support our roadmap, AND successfully put a new design system into production. Our work was visible in every other presentation that week and the vibe of the event was enthusiastic.

Although the new design system was deemed a success, I want take you behind the scenes to explain why it was a critical milestone in building towards our success in 2020.

November 2018

Although I’m based in New Jersey, it’s not uncommon for me to travel to our office in Maryland. One week, I drove down with the intensions of formalizing a plan to roll out a design system with our UX designer.

At dinner that evening, my boss, our VP of Product, and I had a conversation along these lines:

“So… what brings you into town this time?”

“I came down because we are working on a plan to roll out a design system. It’s part of leveling up how we work, which once finished will help free up our time to focus on other impactful things like doing more research and testing.”

“Oh, interesting… I can think of about 5 or 6 major projects we have on the roadmap right now. Since you’re here, wouldn’t it make more sense to be working on designs for those?”

“Maybe, maybe not… think about it like this… I’m not worried about us delivering on the 6 projects as they approach, however, I am worried that over time each project is designed slightly different. We can either spend the time designing 6 different things, or, we can take the time to establish a single library and apply it to 6 projects.”

“Huh… ok. Well, as long as we aren’t missing our deadlines.

• • •

Why a design system?

The generic reasons

Design libraries are not only a best practice but a sign of team and product maturity. It was clear that the UI of our application had slowly gotten away from us and it was time to do something about it. Besides the visual inconsistencies, the aesthetic style hadn’t changed since its original conception back in 2014. It was time for an update.

The strategic reasons

As a newly established design team, I wanted us to make a splash.

In order to do that, I wanted to have two things on our side:

  • Solid evidence that user research had a positive impact on project scope, prioritization, and quality
  • The broader perception that we’ve upped our game aesthetically from those not involved in product

This effort would also positively impact our team in two ways…

It helped a team member find his legs

At the time we had a UX designer who was struggling to find his feet. Working with graphics software was in his comfort zone and implementing a design system was a great project for him to demonstrate his skillset. This project was a way to push that UX designer to get more familiar with the ins and outs of our application. Beyond that, it also served as a way to help build reassurance in his work and gave him more confidence.

Its a tool that speeds up onboarding new designers

In the case that we do invest in design, it makes onboarding new designers easier.

• • •

Project Requirements

  • All UI elements should be WCAG AA compliant or more ideally AAA compliant where possible.
  • Each component should support the concept of a light and dark mode (which will reduce eye strain for intel analysts).
  • The library needs to be approachable and easy to use. After narrowing in on concepts through wireframes, we should be able to build high fidelity designs quickly.
  • When using a component, the overrides should only support realistic states to avoid inconsistent use or unintentional customization.
  • If a component or color is not used in practice, it should not be part of the library. Even though it “completes the set” and makes you feel warm and fuzzy inside when viewing the library in isolation, it dilutes the value of the project.
  • The library needs to be branded. By giving it a strong name, it’s easier for people to discuss it, and therefore it can more easily become an established thing in our culture. In this case, a group of rhinos (ThreatQ’s mascot) is called a “crash”… hence Crash Kit.

• • •

Organizing the library in Sketch

Sketch has come a long way with symbol management, but still leaves a lot to be desired. It’s pretty easy to go down the rabbit hole, organizing and then reorganizing your symbols in search of the ideal menu structure. Not to mention, it’s completely subjective.

Just like when building software, I was able to prototype and test how we organize our components via a bullet point list in a Google Doc before committing to building it out in Sketch.


• • •

Pitfalls to Avoid

This is the second time I’ve put an enterprise level design system into production for an existing application. This time went much smoother than the last.

Roll out in phases, stay organized, and keep the team informed

In order to make the transition as smooth as possible, the design team worked hand in hand with our frontend devs and QA automation teams.

Furthermore, before and during the project, I presented the scope of each milestone and expected delivery date repeatedly to multiple groups of people throughout the company.

Don’t fix anything!… at first.

Allow me to explain.

At a previous company, with less experience, I had the opportunity to implement a design system.

With the best intentions, a developer and I planned our course of attack and executed. We were excited, it was finally our chance to rectify tons of UI issues we weren’t able to fix for years.

For weeks we worked our asses off and after shipping the new updates, our customers hated it. We fixed the handful of UI issues that drove us crazy, but more notably, we also made drastic changes to their workflows.

When rolling out the design library at ThreatQuotient we were much more successful.

Yes, we addressed some of our UI issues, however, we did it strategically with a focus on not changing workflows.

Once the system was fully in production, we were then able to make more dramatic improvements on a case by case basis.

Which leads me to my next point…

Minimal customer response is a great response

As we continued to ship updates to our UI we held our ear to the ground waiting for a reaction.

One day in our customer Slack channel, a customer stated:

“Woah, we just updated and everything looks a bit different…”

After following up with a handful of customers the general consensus was that they noticed the UI update, however, they quickly went about their business since “nothing had really changed”.

It was validation our plan had worked.

• • •

Crash Kit in action…

Below you’ll see both the dark and light variations of our Dashboard and Threat Library pages in ThreatQ.

In summary

If you ask anyone at the company, it’s undeniable that our product has matured a great deal over the last year. In regards to design, our processes have improved, we’re more driven by user research than ever, and we’ve dramatically updated our UI aesthetics game.

I can’t think of a better project to help reinforce that things are on the up and up in such a tangible way.