Based in the Bay Area with 250+ employees and $161 million in venture capital funding, Sumo Logic serves some of the top enterprises in the world. The company’s analytics platform visualizes more than 100 petabytes of data per day, helping businesses harness the power of machine data to streamline operations.
To make the data actionable for customers, Sumo Logic has invested heavily in its own internal UX team to bring a “consumer-grade” experience to the enterprise. In 2015, they hired their first UX team comprised of design leaders, interaction designers, visual designers, and UX architects.
In the beginning, their VP of Design Michael Peachey also defined a clear vision for the UX team: “A Sumo Logic organization where each of us are connected deeply and emotionally to the individuals we serve.” This foundation still drives the purpose of all their collaborative design within the organization.
Across the organization, the design process is defined by design thinking: creating a hypothesis, testing with users, gathering feedback and improving. For Design Director Daniel Castro and team, their unique “Swarm” sessions have been the key collaborative activity connecting all the discovery, design, and iteration.
As a result, the product team builds a design culture through immersion rather than preaching.
One of Sumo Logic’s most important first moves is reaching out to the customer success team, who they consider their “brothers in arms”. Daniel tries to interview at least 3–5 users directly to understand their pain points and needs before doing anything else on a project.
After interviews, the design team starts visualizing the feedback and insights.
Daniel and the team will draw out the customer journey through spreadsheets, flow charts and even cartoons. They’ll also filter through their early concepts and vet them with a larger group of engineers, product managers and customer success team members.
For deep exploration of the problem, they might hold a focused “Swarm” session lasting anywhere between 2–5 days.
Once the team starts to see the requirements shaping up, the PMs will start planning the project so that the design team can work one sprint ahead of development ( e.g. Sprint 16 is dedicated to visual design that developers build in Sprint 17). The product team also plans for a steady cadence of usability testing (e.g. Sprint 15 is testing, Sprint 18 is testing) so that the PM can recruit users and the UX team can run the tests.
Once the team aligns to a solid plan, the team will hold a quick design kickoff with just a basic agenda–no formal design briefs allowed. Attending this first meeting are the designers, product managers and UI developers, who are an integrated part of the product team.
Along the way, they will create some early product specs, but they prefer prototyping in a to create “living documentation” instead of drafting thick specs documents. Since UI developers are part of the UX team, the close collaboration minimizes the need for paper trails.
“Documentation doesn’t need to live in a document. You can be nimbler, like Slacking your team a screenshot of your whiteboard,” Daniel says. “To convey more detail, I’ll create a quick UXPin prototype and share with the team instead of marking up a huge specs document. I can just drag and drop objects from the dozens of libraries to convey the concept. The platform really shines at helping us create collaborative visualizations to help PMs and developers understand the horizontal and vertical requirements.”
After this discovery, the team asks themselves if the prototyped concepts feel viable and feasible. If the answer is no, they’ll dive into another sprint for research and exploration (e.g. “Sprint 0”). As Daniel explains of the discovery process, “A designer’s deliverables is answering these questions, not generating paper documents.”
Sumo Logic’s design discipline centers around the idea of diving deep into chunks of work.
Once concepts are approved to be fleshed out further, the engineering and product teams start looking at their overall projects and breaking them into smaller bites.
Within this approach is the sub-discipline of the design–the “Swarm” or “UX Palooza” as they are also called. While the team generally conducts Swarms early in the product development process, they treat the activity as a tool that works even later in design crunch time.
Every month, the UX team clears their calendar for 2 days (and up to 5), focusing on a specific problem that will help move the overall project forward. They will also notify stakeholders and subject matter experts to set aside a few hours of time to give feedback on ideas. The Swarms evolved from work sessions where the UX team would spend ~3 hours with a subject matter experts churning on a problem. These sessions were so successful that the design team ended up formalizing the process.
“The Swarm is not a blue skies session; it’s more like a war room,” Daniel explained. “We gather everyone together, regardless of what project folks are working on, and put them on task to solve a certain thing. By focusing intently as a team, we can move projects forward and overcome obstacles faster than scattered 1-hour sessions.”
The Swarm Process
The Sumo Logic team communicates via Slack, so the first step is to align everyone’s schedules, give the Swarm a name, and build some major hype (and therefore excitement) around the project. The team prefers holding Swarms earlier in the week, such as Tuesdays and Wednesdays (rarely Mondays for a million obvious reasons) so that Thursdays and Fridays are dedicated to hashing out the details.
As noted, all designers jump into the project and help (even if they aren’t already part of the overall work), which lets fresh thinking be introduced into the mix.
The agenda for the swarm will include two to three initiatives at most, with the goal of coming out on the other end of the second day with something concrete. While the design team is split into two smaller teams to accomplish these goals, the teams are encouraged to cross-pollinate ideas.
Daniel also noted that the key is strategically inviting stakeholders to these sessions–they don’t need to be present for the whole time. Focus is the absolute key to preventing design by committee.
A typical 2-day Swarm looks like this:
- The day starts with a quick debrief.
- Two smaller teams are formed to tackle two projects. Since everyone works in the same room, cross-pollination can organically happen. As Daniel explained, “They hear each other’s ideas and evolve their designs together.”
- First Check-in: Typically after lunch, both teams meet and share their progress so far, discussing obstacles and potential solutions. They may also invite outside stakeholders and SMEs for quick feedback.
- Teams return to work sketching or lo-fi prototyping in platforms like UXPin. Feedback surfaces in real-time within their dedicated Slack channel.
- Second Check-in: Around 4PM, both teams re-huddle and quickly plan their actions for the next day. At this point, the check-in focuses on tracking progress rather than decisionmaking.
“Day one gives you a good sense of what day two will look like,” Daniel says. “By 5 p.m. you’re fried but excited because the whole team is working together, keeping it light and fun while making major progress. The process has really made us a collaborative group. Designers, developers and product managers alike have been sucked in along the way.”
- The day starts with a sanity check on expectations. The second day, as Daniel noted, is “all about the finish line.” For Swarms held later in the design process, the team spends time talking about what kind of visual designs or hi-fi prototypes they need to refine the concepts from the first day.
- Third Check-in: The final checkpoint of the swarm. Typically subject matter experts will return for to give feedback on the refined prototypes. Any fine-tuning will then take place.
- The last meeting is a show and tell, which is less about input than sharing to a larger audience including the VP of Design and other executive stakeholders. The team guides stakeholders to focus on the overall strategy rather than design minutiae. To dive into feedback in more detail with vocal stakeholders, the team will hold ad-hoc 1:1 sessions to give them the right forum.
“You often hear how design doesn’t get the same seat at the table as engineering or sales do at the enterprise level, but Sumo Logic is an example of the complete opposite,” Daniel says. “The fact is that by publicizing our Swarms and inviting the larger company to our show-and-tells, design has achieved amazing visibility within the entire organization. We immerse the company in design, letting us change the culture by experience rather than trying to preach.”
By holding high-visibility Swarms, the UX team is able to showcase solutions to business problems in as little as 2 days at any point in the product development process. In doing so, the quick wins also earn buy-in for additional research or iteration.
UX is therefore perceived less as a “soft” social science and more as a bottom-line force multiplier.
Iteration & Testing
After the Swarm session, the design team returns to the sprint schedule. They will continue iterating and testing their designs with users.
Sumo Logic is also unique in how they run their usability testing sessions.
For users who want to test products but can’t be accommodated in the schedule, the design team will actually invite them to observe tests alongside the designers. In doing so, they’ve revealed surprising insights. For example, a test participant might say out loud that they love seeing a ton of data in a new dashboard, but the 3 users watching might mention the density is overwhelming.
Once everyone is comfortable with the design, the project moves into development sprints. The UX team stays involved with development as the project moves toward the finish line.
Even in development, sprints still account for usability testing. Given that Sumo Logic launches features incrementally, the team can check in and iterate regularly, running additional customer interviews and staying in close contact with customer support throughout the process.
In closing, let’s summarize the takeaways from Sumo Logic’s design process:
- Participatory design is the strongest form of UX evangelization.
- Planning for design work a sprint ahead of development allows more time for work sessions and ad-hoc user research.
- More focused workshops (e.g. Swarms) improves visibility and efficiency of the product team than scattered work sessions.
- Inviting vocal stakeholders to 1:1 feedback sessions isolates risk of design by committee.
“Communication is the bloodline of design,” Daniel says. “You can make the greatest design, but if you communicate poorly, your ideas will fail. At Sumo Logic, we’ve built a culture where designers, developers and product managers work together, collaborating every step of the way in a focused manner. The result has been great products for our customers and a really rewarding work experience for our teams.”
For more detailed design processes from top companies, check out the guide UX Design in Action.