Sentinel Intrusion Prevention Systems isn’t new to cyber security.
They’re a bootstrapped company that’s been around since 1995 and (much like music, tech, and everything else from the 90s) have evolved a handful of times to stay competitive.
These days, they have their eyes on a new transformation...but they needed a partner who could build the foundation for their next evolution.
That foundation is called HQ.
It’s home to millions of points of data. But it isn’t just beautiful software that empowers support and retains Sentinel’s customers — it’s the critical foundation Sentinel stands on as they evolve, differentiate themselves, and communicate value to customers in a rapidly changing market.
Here’s how both teams pulled it off.
HQ as the critical foundation for Sentinel’s evolution
To understand Sentinel’s latest transformation, it helps to trace where they’ve been:
- Back in the infant days of the World Wide Web, they were a team of web developers.
- Not too long after, they switched to network security.
- In more recent years, they’ve grown up as an intrusion prevention systems company.
- And now, they’re evolving into something a bit different — managed services built around network detection and response.
That last evolution? It’s critical.
The intrusion prevention systems market is changing. To remain competitive, differentiate themselves, and deliver clear value to customers, Sentinel has to change as well.
But they had a roadblock.
Think of it this way: When we met them, Sentinel knew where they wanted to get to (managed services built around network detection and response) and which steps they had to take to get there (e.g. data enrichment and better visibility into networks). But a year or so ago, their pain point was they didn’t have an effective way to bridge this gap.
Their roadblock was this: they were missing HQ.
Ted Gruenloh, COO at Sentinel, explained, “Sentinel HQ plays a key role in that transition because it allows us to do analysis on a global scale across all of our customers internally.”
But don’t get me wrong, HQ isn’t just a critical long-term play.
In the short-term, it also positively impacts the following:
- Internal support abilities: A while ago, Sentinel’s technology was what made them unique. These days, their support service is one of their biggest differentiators. Customers can reach an experienced human, 24/7/365 when they encounter an issue. (A rarity these days — how many layers do you have to go through when you have an issue with Google or Netflix?) HQ helps Sentinel’s incredible support do their job even better. This is crucial since Sentinel’s customer base is small, crunched IT teams who rely on personalized support.
“When our customers pick up the phone and call us, they get someone technical immediately and their problem is usually solved in a couple of hours, sometimes even a few minutes.”
Chris Gathright, CTO
- Account retention: Customers have asked Sentinel for this feature for some time. Delivering it demonstrates Sentinel hears their customers and acts on their behalf, which positively impacts account retention.
- Brand impression: The updated design looks and feels nice to customers. Every time a customer enjoys interacting with it, that’s a positive brand interaction they have with Sentinel. Over time, the cumulative impact of these positive impressions strengthens the Sentinel’s relationships with customers.
“...their design is forward-thinking and forward-looking and therefore it makes us look better.”
Ted Gruenloh, COO
That’s the big picture. Here’s the story of pulling it all together.
The vision: Complex data on one screen
The vision for HQ is one place where both Sentinel and their customers can access a lot of complex data on one screen.
To understand why that’s essential, let’s sketch a 10,000ft picture of Sentinel’s offerings:
Sentinel is a hardware, software, and service company. This triple combo (plus an affordable price) is what makes them attractive to their customers — small, stretched-thin IT teams.
On the hardware side, the star of the show is called Sentinel Outpost. It sits at the network gateway and functions as an edge protection device. (Fun fact: it can reduce a firewall’s workload up to 70%!)
Now, a few years ago, if you wanted to see what was happening in an Outpost, you logged into it. This worked fine...until customers had more than one Outpost. Then, Sentinel and their customers had to log into each Outpost to see what was happening (effective but inefficient).
Sentinel realized they needed some kind of digital headquarters. They needed a single pane of glass where customers and Sentinel support could see what was happening in all Outposts at one time.
They needed HQ. So, they set out to build it.
The DIY approach: from spreadsheets to internal hires
Sentinel took several steps to bring the first iterations of HQ together:
- An initial spreadsheet
- An internal system to track multiple Outposts
- A third party team to turn the internal system into a basic customer-facing product
- A full-time employee to re-build and improve the customer-facing product
Each of these steps was movement forward. The spreadsheet led to the internal system which led to the basic concept. And even though the initial concept was clunky and difficult to manage, Sentinel was confident a better version would be a critical factor for scaling.
Sentinel was moving forward on HQ, so what was the problem?
Progress was slow.
HQ is essential to Sentinel’s evolution, but at this point, it was a far cry from the solution it needed to be. Worse, a year into trying to create that solution, Sentinel had the sinking feeling they were starting to fall behind.
That’s when someone referred them to us.
Building out HQ: the software Sentinel relies on today
Like all good things, building HQ didn’t happen overnight. From meeting with Sentinel to where we are now, here’s what pulling it together involved:
- Understanding the data: What is it and what are we trying to do? Where should each piece of data live?
- Representing the data: Which pieces are most important and how do we visualize those? What signals are users looking for?
- Including actual users: Do plans and designs align with real needs and workflows?
- Building it out: How do we compile all the research and designs into a launched app?
- Making improvements: How can we listen to the support team and customers to improve HQ over time?
Here’s how Sentinel and our team worked through each step.
1. Oysters, trust-building, and understanding a massive data set
As any founder or team leader knows, it’s challenging to take an idea from your head (let alone a niche, technical one!) and effectively communicate it to a third party. That’s part of what Roadmapping Sessions are designed to help with.
Something else they’re designed to do? Create a plan based on business needs before you build a product.
Without a clear, agreed on plan, it’s easy to waste thousands of dollars and months of development time (a mistake no founder or partner ever wants to make). Discovery — diving into vision, customers, business goals, and more — safeguards against that, ensuring time and money goes exactly where it needs to.
That’s what we did with Sentinel. During a few packed days of meetings and brainstorming, we asked Sentinel some hard questions, and they threw some hard ones back at us. And while Ted (Sentinel’s COO) wasn’t a huge fan of the oysters we had one night, he and Chris (Sentinel’s CTO) leaned into the process.
“It [Roadmapping] was about establishing trust. We like these guys and we’re going to continue to work with them and we feel like they can actually handle it.”
Chris
By the end of it, we collectively determined a few things:
- Sentinel had a massive and complex dataset, with subsets unique to each customer. We were going to need to compile various sets of data and present it in a helpful, attractive, and approachable way to make HQ a success.
- To tackle this, we broke development into two phases: (1) redesign and visibility, and (2) configuration (Sentinel needed a bit of time to work up to phase 2, so the phased approach was ideal for both teams).
- Phase 1 was going to require a fresh start on the HQ codebase; the Alpha version needed to be scrapped and rebuilt for maximum usability.
- Sentinel is a technical team with experience building technical products. They have opinions about technology and design — and that was going to be an enormous help. Especially considering we’d need to work alongside their team to simplify and unify their overall environment!
After Roadmapping, we were all on the same page about where to go. Now, it was time to start getting there.
2. Tying data, expertise, and design into a seamless experience
One of our first steps was wrapping our heads around the data and thinking through how it flowed through various screens.
To do this, we created wireframes — or high-level sketches — of what happens on each screen.
It’s important to note these wireframes didn’t float straight out of Austin Price’s (Partner and Lead Designer at Krit) head. To create wireframes, we pulled from several key resources:
- Real data: We used a JSON file of different data models and sample data. This way, we didn’t assume text would be a string of ten characters when it was actually a paragraph.
- Sentinel’s expertise: Chris worked closely with us to illuminate niche terms we didn’t understand and explain exactly what customers were looking for on each screen. He provided essential content expertise.
- Our design & product knowledge: We used years of experience designing products and apps to architect workflows that were easy to use and understand.
Then, we refined those wireframes with more input from Sentinel. Once we nailed down how the app flowed (wireframes), it was time to dive into what each screen looked like in more detail (mockups).
3. Crafting designs around Sentinel’s customer base and experienced support team
Whereas the wireframes pictured the structure of each screen, the mockups detailed the look and feel of each screen.
Think of it this way: a blueprint (wireframes) shows you the dimensions and layout of each room. You know how one room connects to another, where the doors and windows are, and what furniture it can hold. That’s all wireframe material. Next, you consider the wall color, textiles, furniture style, and other nitty-gritty details. That’s what mockups show.
In app terms, figuring out the look and feel of each screen means defining “base styles”:
- Fonts
- Colors
- Headers
- Form elements
- Other stylistic elements
And then translating those base styles onto every app screen in mockups. These mockups are so detailed, they look like a working app (that’s why they’re called “high-fidelity mockups”).
But again, this wasn’t simply Krit deciding what the app should look like. While we certainly drew on our extensive design experience, we also relied heavily on Chris and Ted, as well as end-users of the app.
Incorporating subject-matter expertise from Chris and Ted
When Austin delivered the first round of mockups, there was a good deal of back and forth — and that’s a healthy thing!
Austin recalls, “Chris and Ted care a lot about getting the design piece right. We’ve never gone through design and not gotten feedback.” From Sentinel’s perspective, Chris says, “We do have opinions. And one reason we like Krit is we’re comfortable with them and we feel like they’re a little bit like us...we just cut past a lot of the fluff. And now we’re even more comfortable with them where we’re not worried about stepping on their toes.”
“...people can get personally attached to what they build and it’s difficult to give critique...Krit handles that really well, which we love.”
Chris
Collecting end-user feedback through user testing
Once we revised mockups with Chris and Ted’s feedback, Austin set up a series of interviews with the two parties who would use HQ regularly: Sentinel’s support team and Sentinel’s clients.
Now, collecting feedback from folks who will actually use the app may seem like a no-brainer, but it’s a step many companies skip. That’s unfortunate because it’s an incredibly effective way to find points of friction while building customer loyalty.
In Sentinel’s user interview, Austin walked each interviewee through a clickable prototype and observed them completing key tasks. Then he attentively listened and gathered feedback.
This user testing did two important things:
- Gathered crucial feedback: Putting a clickable prototype in front of the people who use it identified important holes and sticking points. For example, some users were confused by certain colors and text labels or struggled to open a support ticket. Knowing this took the guesswork out of what improvements we needed to make next. It also ensured we caught any major usability issues before building the product. (It’s much harder and more expensive to fix those issues later.)
- Signaled progress to active customers: Several customers knew HQ was in the works and were anxious to receive it. Including these customers in design reviews signaled, “We’re working on this and making progress.” It demonstrated Sentinel was actively listening to their customers, which helps build loyalty and improve retention.
“We wanted our customers to know we were working on something. It’s a great way to signal, ‘Hey, we’re actually working on this and we’re making progress.' Because if they don’t see movement, they may just assume there’s no movement.”
Chris
Once we compiled our findings from user testing and improved designs with those findings, it was time for our developers to build out Sentinel’s HQ.
4. Building and launching to a loyal group of customers
While Austin was wrapping up designs, our development team started work on application setup. This meant activities like:
- Creating a single page in the application that contains all the design elements
- Researching and signing up for 3rd party resources
- Basic app configuration
- API configuration and documentation
From there, it was a lot of “head down” sprints to bring HQ to life. While Sentinel was safeguarding customers and working on the day-to-day business activities that saturate their time, we were working on HQ.
“We had peace of mind knowing, ‘okay we’re fighting a fire at this moment that we didn’t expect to...but that’s okay because Sentinel HQ is still moving forward, and Krit is still working on it.’”
Chris
In under 4 months, Sentinel had the chance to see the beta software in action.
After some back-and-forth, internal testing, and revisions, both parties were excited to share the app with the world, and Sentinel released the app to a few customers in a traditional beta launch.
“Once we got that first beta up and we had that data flowing, that’s when we realized, ‘This was the right decision.’”
Chris
What they heard was encouraging. The most common responses were either, “Wow, this looks awesome!” or radio silence — a good sign in beta because silence means the customer can and is using the product with ease!
Introducing Sentinel HQ: a powerful single pane of glass
Sentinel HQ is now live for Sentinel’s support team and clients. It:
- Condenses millions of pieces of data into intuitive charts and displays
- Highlights critical alerts and notifications plus latest vulnerability scans
- Gives customers with multiple installations a mission control to view all activity
- Enables Sentinel’s internal support team to quickly assess installations and address support requests
- Establishes a “home base” for future improvements and powerful features Sentinel has planned
Here are a few other pieces and details worth noting.
Condensing millions of alerts onto one attractive screen
Garrett Vangilder, one of Krit’s talented developers, used Vue.js for the frontend to build screens like the aggregated alerts dashboard, where analysts can check alerts over time.
This was no small feat design-wise or technically.
For example, there are over 700 rows of data in one table, which is a lot for a browser to load in one go. To solve this particular performance problem, Garrett built the table to dynamically load as the user scrolls. This creates a seamless and fast experience on the whole page — from the moment it loads to the moment a user dives deeper into data.
But that’s not all Garrett needed to sort out. Pulling in alerts was further complicated by a sharded database. Meaning, when we wanted to query a specific piece of information, we often had to look in a variety of places (shards) to retrieve it.
Think of it this way:
- Some databases are like one big walk-in closet. All your clothes, shoes, t-shirts, belts, whatever, are all in this closet. So, when you need a piece of clothing, you head to one place — the closet.
- A sharded database is more like a room where you keep clothes in a lot of different places: in the closet, in the dresser, under the bed, on the chair, and in that pile in the corner. When you need a piece of clothing in this setting, you might find it in the closet, but chances are you’ll need to check other places too.
While this illustration makes a sharded database seem rather ineffective, it exists for a reason — this setup keeps Sentinel’s database performant and their customers protected.
Now that HQ is live, where to from here?
Since the initial launch, we’ve worked with Sentinel to prioritize improvements like dark mode and better filtering of alerts.
And there’s much more ahead!
We’ve partnered with Sentinel for nearly 2 years now, this is just the beginning for where they plan to go. Sentinel has big plans for the future and their customers, and we’re incredibly excited to help them move one step closer to their goals.
“We’ve had the best possible experience we could’ve hoped for.”
Chris
What are your plans for keeping up with a changing industry?
If you’re a growing cyber security company figuring out how to scale, we’d love to talk with you, too.
Schedule a free strategy call with Andrew to learn more about the services we offer and how we can help you delight your customers. We’d love to hear from you.
