Valued at more than $3 billion dollars with more than 600,000 paying customers at the start of 2016, Slack is on a mission to simplify how teams communicate—a philosophy echoed in the company's own design process.

The company, which has more than 400 employees, has a rare internal resource: a huge, pool of employees to user test with. Since all employees across the company dogfood Slack every day for eight hours or more a day, the Slack design team enjoys unprecedented access to feedback from users who have an intimate knowledge of the product. As a result, Slack’s design process mirrors the open communication that the company was created to foster.

FROM "A VAGUELY DEFINED PROBLEM STATEMENT" TO PRODUCT BRIEF

Diogenes Brito, product designer and engineer at Slack’s San Francisco headquarters, explains that most product ideas and feature requests start as "a vaguely defined problem statement" driven either by customer support tickets, feedback within Slack’s product channels and social media, or the company’s own product teams.

As one of the first steps in solidifying the project, the product manager and designer meet together to record ideas in one place.

This initial document is a product brief that, as Diogenes says, is "really about the spirit of the project, seeking to define the core goal and the nuances of the problem" so everyone has the right context for the follow-up kickoff meeting. The brief is in fact a living document that will evolve throughout the entire process.

Indeed, while the core of the brief will stay the same once the project details are finalized, the brief becomes a focal point for design reviews and serves as an artifact of all that was done once the project is complete. It will even be used as the core asset for final executive review.

The brief not only consolidates ideas in one place, but it also gathers constraints.

Questions covered in the brief include:

What does the team care about the most?
What is in scope, and what isn’t?
What does success look like, and how will we measure that?

"The brief is not prescriptive but more about asking the right questions so we can explore in the right way, knowing the boundaries of the problem," Diogenes explains.

THE KICKOFF

Once the brief is ready, the lead designer and product manager will hold a kickoff with the larger team. At this point, some preliminary ideas may be covered (and the designer may have completed some exploration with rough mock-ups or wireframes to act as a visual aid).

Regardless, at the kickoff, the team always reviews the entirety of the brief to ensure everyone fully understands the project and can air their core ideas and concerns.

The kickoff helps everyone understand the design problems and goals, while also discussing any burning ideas. The kickoff is not meant as a free-form brainstorming session.

PAIR DESIGN

Once the kickoff finishes, designers and developers begin their exploration and specification in tandem, checking in with each other informally throughout the process in Slack.

What is formalized is that designers always work in pairs, with one acting as the lead designer. Diogenes compares the relationship to the tennis stars Serena and Venus Williams in a doubles match, noting they are both amazing but one person is usually leading and serving.

"Pair design gives you a partner in crime to help you explore ideas more," Diogenes explains. "It’s two people with similar or complementary skills riffing off each other. Plus when you have two people, it helps you get unstuck faster when you hit a roadblock."

Both designers work on different design problems, but regularly brainstorm concepts and cross-pollinate ideas. Other team members may also involve themselves with the pair for consensus building and informal brainstorming, but the team prefers impromptu activities to formally scheduled workshops.

While the designers are exploring concepts, the developers are also exploring relevant parts of the code base and overall technical constraints. Once the two groups feel confident about their understanding of constraints, the whole team will hold a "post-kickoff" to review the product and technical requirements.

Following the post-kickoff, design critiques happen twice a week. When a designer feels ready, they bring their work for feedback from the larger product team. While the larger team may offer feedback to the design pair, the "lead" designer remains the clear point of contact with the product manager.

This point person remains in place all the way through final design review, which includes product leadership and the CEO Stewart Butterfield.

FREEDOM IN DESIGN TOOLS

Instead of following strict protocol, Slack designers alternate between sketching and low- and high-fidelity prototypes when designing, using the right tool for the problem at hand.

"The big thing for us is not whether we do a wireframe, a mockup, or high-fidelity prototypes," Diogenes explains. "It’s about thinking about the question and using the best tool to arrive at the answer with the least amount of work."

For example, when Diogenes was working on a new auto-complete feature, he created a number of low-fidelity prototypes to answer questions around the core interaction model. But when he encountered tricky micro-interactions, he would build working prototypes in code to finalize the details.

"Sometimes we can go right to design from sketching because we know our product so well." he says. "We use whatever tools we are the fastest in–-and that varies from paper, Keynote, HTML, to a collaborative design platform depending on the project."

DOGFOODING AND USABILITY TESTING

At Slack, usability testing is not usually a separate item in the design process. Instead, user testing is ongoing because of their massive internal user base.

For example when the team decided to add voice calls, they designed and then released the feature internally, rolling it out very slowly in-house and then to an external beta before eventually to the whole user base.

"We use our intuition," Diogenes explains. "But it is finely tuned because we all use the product for hours every day. User feedback is also regularly trickling in from outside of the company, and everyone serves weekly support shifts to better empathize with customers."

Indeed, within the walls of Slack HQ in San Francisco, the design team can test different user scenarios with its own departments. Each department acts as a microcosm of the larger customer base.

For example, designers can learn more about how to improve Slack for finance teams by observing and gathering feedback from its own finance department.

In addition to dogfooding, they also regularly prioritize a steady stream of feedback as it trickles into their customer support Slack channel. That said, when they do embark on brand-new features or new audiences—such as international or enterprise-sized teams—the design team will conduct generative field research and more traditional moderated user testing to expand their knowledge.

"Our company is like a 24/7 lab for us," Diogenes adds. "And because we are all in the product all the time, no issues can just get swept under the rug."

SPRINT TO THE FINISH

Once design is complete, the team moves to a development sprint model. Nonetheless, sprints remain flexible in case unforeseen challenges appear. By the time the product team reaches the sprint stage, most design work is done and the designers focus on offering support and quality control.

Aside from constantly communicating via Slack, the team also holds standups in their channels or in-person as needed.

"Transparency is key to our product and our culture," Diogenes says. "These same core values inform our design process, making it truly organic and effective. And because we use Slack every day ourselves, new ideas keep coming every day—that’s a serious competitive advantage."

CONCLUSION

Slack’s organic design process shows that structured design isn’t the option for startups and enterprises. Flexible processes for concept exploration paired with structured development can deliver successful products, so long as regular research and testing validates the progress.

In closing, we offer the following takeaways:

In a product brief, don’t prescribe the solution. Focus more on describing the context around the problem and suggestions for various strategies.
After the initial product kickoff, allow the team freedom to explore concepts and discover constraints. Merge development and UX insights by then holding a post-kickoff review to formalize constraints.
If your team structure allows, consider pair design for richer idea generation and faster problem solving.
If your company’s employees are similar to your target users, regularly dogfood the product for guerilla research. Internal feedback and testing builds a solid foundation of usability knowledge that you can expand through further field research.