Slack: A Look Inside Design at the World’s Top Companies

This is part 1 of a 3-part series where I take a look at design at some of the world’s top companies

---

 

Designing in an enterprise is hard. Have you heard these phrases in your work?

“That’s not how things work here”

“We’ve never done it like that before”

In enterprise teams, these phrases seem to be particularly common. What about these?

“If we’ve been successful in the past, why change?”

“There’s no way we can change our process while also balancing the current load of projects”

Creating more effective processes isn’t simple or easy, but it is necessary. In today’s ever changing markets, where enterprises must contend with an ever expanding list of competitors and technologies, effective design teams are a must. But turning old and slow-moving processes into more adaptive and quick ones is challenging.

A factor compounding this challenge is that each enterprise is unique. What works for one organization will undoubtedly fail in others. Often, teams must navigate complex politics, design with consistency across dozens of touch points and mediums, deal with limited budgets, and collaborate effectively with teams, stakeholders, and departments. None of which is straightforward. In a recent report on the state of Enterprise UX, the top challenges facing organizations include improving design consistency (59%), testing designs with end users (53%), clarifying requirements (46%), and collaborating across teams (44%)

Sound familiar? How about this?

Your team receives a request for a feature, function etc. It’s given in the form of a solution jump.

“It should have this.” “It should do this.” “It should contain these requirements.”

As a UX or Product designer, that might drive you crazy. You are trained to validate with evidence and ask critical questions in the face of all things. Why does it need that function? What problem is it solving? Why should we do that instead of something else? Is there evidence to back up that this proposed solution is best?

And often times: Crickets…

But there is hope for design teams within large organizations struggling to receive greater clarity and implement design activities with greater speed and success. We can look to other organizations for ideas. How do they design successfully? How do they deal with the challenges in their own organizations? What techniques and activities do they use and how do they use them? Why do they use them?

There won’t be a 1:1 fit. That’s inevitable. But there are lessons to be learned. Here, I break down those lessons so your organization can grow, adapt, and create an atmosphere where enterprise design is a bit easier and, ultimately, more successful.

Let’s take a look.

Slack

If you haven’t heard of Slack, you may be living under a rock.

Initially launched in August 2013, Slack has quickly risen as one of the go-to messaging systems for teams. As of late 2017, Slack boasts over 6 million users and is valued at $5 billion. What’s less known is the company was originally named Tiny Speck, founded in Vancouver, Canada in 2009, and led largely by the same team that created Flickr. At first, the company was in game design but pivoted to launch a real-time collaboration app and platform called Slack; an acronym for “Searchable Log of All Conversation and Knowledge”. After receiving angel funding and subsequent Series A, B, and C rounds from 2010 to 2014, they launched the Slack we have all come to know and love.

So you might be wondering, how does design work at Slack? With such a colorful history, what has enabled them to grow so rapidly in ~4 years?

Well, Slack is unique in that they have a huge internal resource they leverage constantly: their own employees. As you might have guessed, everyone at Slack uses Slack. The design team has access to constant user feedback. Coupled with intimate knowledge of the product, they research, test, and iterate extremely quickly and effectively to constantly improve the application. That might be disheartening for teams struggling to access users, user test, and research but there are still many things we can learn from an in-depth view of their process.

Product ideas and feature requests at Slack often come in the form of a vaguely worded and undefined problem statement. They often originate in customer support channels, internal feedback, social channels, or the company’s own product teams. After receiving this content, the product manager and lead designer meet to discuss the project and brainstorm together. The result is a product brief that seeks to define the core goal and nuances of the problem. Questions covered in the brief include:

• What does the team care about the most?
• What is in the scope and what isn’t?
  • What are the boundaries of the problem?
• What are the success measures and how will we measure them?

The next step is a kick-off meeting to ensure the team understands the scope of the project. Rough visuals may be used to act as a guide, but the main goal is to ensure the team is all on the same page. Questions are answered, confusion eliminated, and core ideas and concerns are addressed.

Once the kick-off finishes, both design and development teams use pair design to explore the problem. Pair design is where two people with complementary skills work together on different problems within the same project, but routinely ideate and work through roadblocks together.

Once designers and developers feel confident in their understanding of the problems and constraints, the entire team will hold a meeting to review the technical and product requirements.

Post kick-off, design critiques happen twice a week. Designers will present their project to the product team, receive feedback and iterate their designs. The final design critique will be towards the end of the design phase and include all product leadership and the CEO.

Once the design is complete, the development team uses a sprint model while designers offer support and quality control.

As you can see, the model at Slack is flexible and autonomous. From a design perspective, designers use whatever methods they believe work best. Focusing on the problem or question is championed and methods are viewed as only a way of solving the problem or seeing how things work. They ask, “What is the best tool to arrive at the answer in the shortest amount of time and least amount of work?” Other activities such as usability testing are ongoing at Slack because they are able to test the solution internally very easily. For larger projects, they roll out an internal beta to give themselves an opportunity to get the right solution down before publishing it externally. In addition to dogfooding new releases to internal teams, the product team always reviews customer support channels for feedback.

A Few Additional Take-A-Ways

• Instead of jumping right to the solution, describe the context around the problem and seek to define the core goal and nuances of the problem. From there, suggest a few different strategies to maintain focus when coming up with solutions. Focusing on the problem will lay important groundwork to keep the team aligned throughout the design phase. If you start with a solution, different people will find different reasons for its validity and head off in different directions. The result will be misalignment within the team and ineffective decision making.  A good question to hold in reserve when team members solution jump is to ask, “What problem does your solution solve?” To follow, print off a problem statement worksheet like this one to use in your next meeting. Your users may have many different problems that require many problem statements. That’s okay. The goal is to agree upon the problem and have a consistent way of talking about it.
  • (Users)_____________ need a way to _____________________(user need) because ________________ (insight).
• After initial kick-off, allow team members autonomy to explore concepts and discover constraints. Consider pair design for collaborative ideation and quicker problem solving. Merge development and design insights to formalize requirements and constraints before the meat of the design work begins.
• If your company users are similar to your target users, consider dogfooding. Internal feedback and testing will build a foundation of usability knowledge. If not, consider guerrilla research tactics or more formal tools such as product analytics, heat-mapping, unmoderated and moderated usability testing, and surveys.

Check back next week for an in-depth look at 3M Healthcare’s design practice.