Background
Security professionals need to know the moment something suspicious happens in their environment so they can begin investigating the cause. They rely on different tools that monitor different parts of their environment, to build context and form a hypothesis of what may be going wrong, before it escalates any further.
This is a time sensitive operation. Analysts are constantly context switching and pulling in different sources for comparison. The cognitive overload adds even more pressure to this already high-stakes process. Though my product team’s tool provides valuable analytics and alerting around database traffic, it is yet another tool that an analyst needs to log into in order to get value.
Users
Scott, Security Admin
Responsible for the day to day tasks that keeps the company’s infrastructure and apps secure, compliant, running and useful to others
Mei, Incident Response Analyst
Monitors alerts on important assets, and takes the time to thoroughly investigate and respond to a security incident
Problem statement
Scott, a security admin, needs a way to send time-sensitive information to other tools, so that Mei, an incident response analyst, can compare against other data without having to context switch.
Process
The team
This project happened in tandem with a bigger, more high priority project. Due to limited resources, my teammate and I took turns owning this project. Whoever had some extra availability in a given sprint would move it a little closer to the finish line. I will point out which contributions were mine, and which were his.
Understanding user needs
Starting out this project with little direction, I initiated my own investigation into areas of opportunity and users’ expectations.
I looked to the current experience around alerts in our legacy product to understand what are the steps a user must take to set up alerting. Based on that, I decided to break this project into two work streams:
- Configuring integrations (Where does this data need to go?)
- Sending alerts (How will it get there?)
I documented my questions and assumption, as well as any initial ideas I had to simplify the experience.
Without access to users, I set up my own round of research with two technical sales representatives, who have regular interactions with users of our legacy product. I used these discussions to answer my questions and create a draft of requirements for this work. These requirements became the basis of my early low fidelity explorations.
Considering information architecture
I had a look at the existing information architecture in our Settings menu, to figure out where this experience might live.
As a large product team with different squads delivering different experiences, we hadn’t aligned on any logical grouping or ordering for this menu, and the pages were starting to pile up haphazardly. I took this as an opportunity to revise that menu, rather than continue adding to the disorganization. As an exercise, I invited a technical squad member to create and compare their own logical groupings with my own.
Design Audit
Next, my teammate and I audited existing Integrations experiences. We looked for examples from other IBM Security products, from the greater IBM community, and externally. We specifically looked to understand:
- Where Integrations typically exist in the information architecture
- What patterns are commonly used for showing what’s available and what’s been connected
- The experience of connecting to new integrations
We identified common patterns that we could replicate so that even new users could navigate this experience easily from the start.
Sketching + wireframing
I created low fidelity user flows for the different scenarios and requirements I’d written. I presented my progress at sprint reviews and design critiques for feedback.
After getting alignment on these intial flows, my teammate took the baton for a while and worked on moving the designs to mid fidelity.
Visual design explorations
In my experience, on a continuous delivery team with limited design resources, the visual design phase can often get skipped over. Mid fidelity flows essentially get “colored in” without additional thought going into optimizing layout and hierarchy, simply because there is a massive backlog of work and the team needs to move on. After seeing this play out time and time again on my product teams, I made a point to actually devote time in my sprint to visual design exploration this go around.
Looking at my teammate’s mid fidelity prototype, I flagged 4 screens that had opportunity for further exploration — these screens either had additional complexity, or they didn’t already have an established pattern in our design system that could be relied upon. I created different explorations to see what would be the most effective way visually to display the content. I played with different type styles, layouts, and components.
I met with my teammate to present the various explorations, and discuss the pros and cons of each. From there, I decided which was best, and put together a new prototype to circulate to the rest of the team for feedback and awareness.
Final experience
Working with the development team on delivery
I created detailed design specs for the development team, labeling each screen with our design system’s spacing, color, and typography tokens. For particular questions around unhappy paths, I created additional documentation or use flows to illustrate how the experience should unfold.
I met regularly with them to make sure they had everything they needed. However, since they were located 5 time zones away, I got creative with our communication methods, and often sent videos back and forth to review work in progress and answer any questions.
Lessons learned
- Taking the time to do visual design explorations. As a small design team supporting multiple development squads, we designers have to be very precious with our time. Often, the visual design exploration phase gets skipped over, so we can move onto the next priority. But taking the time to do those explorations here made the designs stronger, more aligned with industry standards and therefore easier for our users.
- Pushing back on undefined work. Although this work was a necessity for the success of our bigger project, my product owner was too busy to be a part of this work, which meant I had to do a lot of the project defining, scoping and investigation myself. While I learned valuable skills and grew in this area, it inevitably drew out the length of the design and delivery process and detracted from my other design commitments. In the future, I will push back on work that is undefined or does not have the explicit buy-in from the product owner.
- Creating design assets for FED delivery. I really considered my teammate’s level of skills when creating handover assets, made sure he was supported, and that I was available for any questions despite being 5 time zones away. I thought of this teammate as a “user” of my design assets, and that allowed me to empathize with his situation as someone implementing my work. I was able to provide better support by reframing our relationship in this way.
