Activity Feed

Design Process

Understand

The Problem
User Journey

Scope

Constraints
Prioritization

Ideate

Audit
Design Iterations

Design

Design Process
Iterations
Prototype

01 Understand

On Mission Control, Splunk's unified security console, Security analysts must navigate through several tabs and screens to gather context on a security incident. In some situations, tens or hundreds of automated actions can be run in a short period in addition to manual activity run by team members. This information is dispersed across several different pages and tabs for security analysts to navigate through.

Moreover, optimizing collaboration between analysts and adjacent teams via ChatOps is essential. Currently, inter-team communication occurs on diverse messaging platforms such as Slack or Microsoft Teams. Varied levels of access to Mission Control among team members create a challenge, necessitating analysts to constantly switch between Mission Control and messaging applications to share crucial insights.

To deepen my understanding of the issue and the objectives of this project, I crafted a potential, current workflow of a security analyst using Mission Control. This document helped Nicholas (PM) and I to pinpoint the pain points they encountered and identify opportunities to enhance the overall user experience.

Drawing from our understanding of the user pain points, we phrased the ensuing problem statement as an actionable question:

How might we congregate activities that occurred within an incident and streamline collaboration between an organization's security analysts and adjacent teams?

02 Scope

To address our problem, we proposed a version 1 solution for the Activity Feed—integrating it with Slack. We deliberated on its presentation, opting for a side panel initially. This choice allows security analysts to review the feed while navigating different pages. If needed, we can consider a dedicated page in the future based on user feedback. We decided to focus on Slack because of its widespread use, with 77% of Fortune 100 companies using Slack as their primary communication tool.

One of the biggest constraints for this project was time. Since there were multiple interns working together on this project, we had hoped to have much of the development concluded by the end of everyone's internships, giving us less than 12 weeks. As a result, we had to navigate numerous technical considerations to produce a Minimum Viable Product (MVP) within the allocated period. The technical constraints were dynamic, evolving throughout the project, introducing new challenges that required us to adapt our design approach. One critical consideration revolved around the integration of Slack into the activity feed—whether to embed Slack directly, preserving its user interface, or to blend Mission Control UI with Slack functionality. This decision ended up being the crux of this project, which you will come to see as you delve deeper into this case study.

03 Ideate

With a clear understanding of our objectives and constraints defined, I started by researching chronological feeds on other applications and competitors to get inspiration. Through my investigations I noted some common patterns.

Tabular vertical view
Filters
Time stamps + users
Redirecting links
Actions

Subsequently, Nicholas and I synced to initiate a brainstorming session on Figma, and explored ideas and potential solutions to the identified issues. During a synchronous call, we leveraged this collaborative session to exchange thoughts, deliberate on tradeoffs, and establish priorities, categorizing features into P0, P1, and P2. Subsequently, Nicholas documented our discussions in a PRD, setting the stage for me to embark on my design explorations.

04 Design

The design process was a roller-coaster of highs and lows. Bi-weekly, I dedicated time to present my latest designs to the product team, facilitating an iterative feedback loop. Navigating through various project iterations became necessary due to frequent technical constraints evolving throughout the development phase. Although the process presented its challenges, it underscored the importance of maintaining close collaboration with developers and cross-functional partners. This experience taught me the significance of aligning design decisions with technical implications, preventing over-investment in concepts yet to be validated.

Interactive Window

In one of my initial design explorations, I envisioned an interactive window akin to the "compose" feature in Gmail or the chat windows in Facebook and LinkedIn. This concept provided users with increased flexibility, allowing them to open multiple incidents simultaneously, as well as minimize or close them to have an unobstructed view of the rest of the page. Despite its configurability advantages over alternatives like the side panel, technical constraints led us to set it aside as a potential idea for future iterations.

Side Panel (Mission Control UI)

Another iteration of the side panel involved designing the side panel experience using Mission Control's native UI. The rationale behind this was to maintain a seamless and connected user experience within Mission Control. However, developers proposed embedding Slack directly into Mission Control's side panel as an iframe, citing the ease of development. Although the team generally agreed that aligning with Mission Control's UI was the ideal long-term solution, we opted for embedding Slack in the initial version. This decision was influenced by users' probable familiarity with the Slack UI, and we aimed to ensure a unified visual experience by customizing Slack's theme to match that of Mission Control.

Side Panel (Slack UI)

For the Slack embedded feed, I designed the experience capturing the end-to-end flow of the activity feed with Slack UI. I researched Slack's design kit to ensure that my designs could be reflected as accurately as possible in the final implementation. I translated the designs to encompass mission control commands and various event types, such as incident creation, playbook execution, status updates, and more.

Following that, I systematically organized my files and crafted a design document ready for hand-off, meticulously detailing all interactions and accounting for potential edge cases.

After the designs had been finalized and the developers were working on implementing the designs, they realized that Slack couldn't be embedded into Mission Control as easily as they had initially anticipated. This resulted in our final pivot of going back to the previous iteration of Mission Control Native UI in the side panel.

Final Designs (Mission Control UI)

Alas, we circled back to the Mission Control side panel. I refined the designs, and after a few rounds of refinement, arrived at the ultimate versions. I created a clean Figma file for design handoff and paired with a front-end developer intern to make sure the implementation reflected the final designs.

Here's a quick demo of the prototype I built on Figma!

Reflection

Design at a fidelity that makes sense.

‍‍The pivots I had to make due to technical limitations cost me several hours of work. From this, I had two major takeaways:

1. When there is ambiguity, start in lower fidelity.
Designing when there is uncertainty, it's beneficial to invest time in crafting diverse low-fidelity solutions rather than prematurely committing to a higher-fidelity one. In the absence of defined requirements for version 1 of the activity feed, I was granted the liberty to explore various concepts. However, I delved into designing an idealistic solution without taking into account the technical feasibility, possibly neglecting the exploration of alternative ideas and opportunities at a lower fidelity.

2. When there is more dependency on technicalities, start in lower fidelity.
Following the developers' suggestion to embed Slack into Mission Control, the project manager agreed that it could serve as a viable initial version for the activity feed. As a result, I focused exclusively on this solution, investing time in designing and prototyping a high-fidelity embedded Slack feed. However, when the developers later realized that the implementation was not feasible, I learned that my efforts had been in vain. In hindsight, I recognize the importance of consulting with developers to validate the feasibility before committing substantial time to a solution. If I could go back, I would have prioritized confirming technical viability before dedicating extensive effort to the design.