Connect with your exact customers
See, hear, and talk to your customers
Uncover insights about any experience
Share key insights across your organization
In a recent webinar, Tina Chen, Design Lead at Slack, takes us behind the scenes to share the design processes at Slack. She talks about what it's like to design at a company that’s growing rapidly and walks us through a recent project that gave apps and bots the ability to interact more closely with users. We had a great Q&A session with Tina and included some of our favorite questions below, or you can watch the full webinar here. Enjoy!
Almost any prototype is testable as long as you’ve framed it well. As long as you have a story to set them up with. So it's not just like, "Here's the thing, what do you want to do with it," it’s more like, "Oh, like you're trying this out for the first time." You want to create something the user is trying to accomplish a task just to set their mind in motion, and show them a mock and walk them through it, I think you could almost take any, even a sketch. I've taken people through just a series of a couple of sketches. As long as you set up a story people are really good at imagining what things.
We do design sprints. They're not super formalized yet. That's something that I would like to do more of here. On the platform or in various places it's just been very informal, like grab a whiteboard for a couple of hours and sketch some stuff out and then schedule some time for a follow-up. It's more like in the discovery phase. For message buttons we probably spend two weeks at the very beginning of the project with two designers doing exploratory stuff which is pretty much I think a design sprint, but we didn't call it as such.
That's a good question. It depends I guess because some features are really, really difficult technically, especially if they restructure the way your system works. The design cycle might actually not be so long but the engineering cycle is really long. Then there are certain features that are very front-end heavy that could take a really long time design-wise to get a really good new system in place if you're doing that. That might not be as much work engineering-wise. It's like primary front end. It's easy to do. For a typical project where you're adding a new feature, you're extending something that generally already exists, I would say design process might be a third or fourth of the overall development time generally. Usually by the time a project has gone through the product review where we're like roughly this is what we're doing, engineering to some extent is starting to think about the problem already. I don't know if you count that as development time. I'd say a third or a quarter is typical for a medium-sized feature.
It's around 15 to 19 people or something like that. We also, in addition to that, have three product writers that are part of the design team. Anna, who's our head of voice, who's responsible for many of the best characteristics of the Slack brand and voice. We're starting to build out a communications design team which also adds to that number. That's kind of partially how it's broken up. Our research team actually sits under product because they do a lot more discovery, really ethnographic which is like deep research on really basic questions and less usability testing right now. Although sometimes the number of people on the team just do usability testing. Then it's in the design team we're split into the core product areas. Everyone is usually either a just a product designer or we have managers for one or multiple sections of the product areas. We are in process of making sure we have all, like a product lead for each area, so somebody who's just responsible for overall design direction and consistency for that area.
That is a good question. I actually haven't been as participatory of that at Slack. I've done that more when I was at Medium and Google. That's generally something that if we have a dedicated researcher that's more of what they're really good at. You start with defining what the important users are and who to focus on. It could be somebody who is brand new. At Medium for writers versus readers are the important split or readers who want to be writers for instance or like somebody who has a successful blog. Those are all very different people. They have differing needs so sectioning them out first is really useful. Then you just recruit for the audience either by usually a survey is really common like you have a survey to screen for just the right type of users. You just broadcast that out to your entire user base. I know some researchers will put ads in various places to try to get people in that way. There are lots of different ways. Usually, a survey is really good for making sure you have that right cohort though. Then you can reuse them a couple of times if you need to.
Yeah, we have a small but mighty research team. I think right now there are three people. They're kind of spread out across all the different product areas. Like I said they're doing more ethnographic research, really deep understanding of some of the fundamental problems and understanding just our user split for instance, like if there's a way that we can identify cohorts of users that are more meaningful. They're doing really deep basic research right now. Our goal is actually to get to hire a few more. I think each product area will have a dedicated researcher which makes it easier to do, deeper research for a particular area.
When people first start here almost everybody goes through a session when we talk about the Slack brand and voice. Things like, "How should you think about it?" and, "What are the do’s or don'ts?" We also have really amazing product writers who are all around. They really help reinforce that. They are kind of spread amongst different teams. They make sure that the copy that's in the product, the way that we talk about it, is really consistent. I think all the writers have a couple of editorial channels in which they'll, much like designers, they basically are designers for words. They'll pitch ideas for, “How do we phrase that?” They'll workshop it.
The answer is everything because they're changing so rapidly. I would say I personally like Framer a lot because I find it very flexible. I also find that InVision and Flinto and there's another really new one that I forget the name of which are more like WYSIWYG, you link things together and you can maybe add some parameters, and are really easy to pick up. Those are almost like if you just want to stitch together a tap-through prototyping flow it's like InVision is really good for that.
I think the most important thing is knowing when to bring developers on board. Again, we try to do that really early. Even if there's actually no code to be written yet, because we don't really know what we're solving, we try to involve engineers that are either on your team that are interested in that area, have a background in it, or potentially could be working on it even though it's not for sure and just involve them in the discovery process. Often they have a lot of insights too, into the overall problem, so by the time you're actually making the design they feel like they are already involved. Also, I really like to show designs really early. Even if they might change a lot, just showing the overall process and getting the feedback at each step, I think a lot of it is just that they have shared ownership of it too.
When we first started this we had four designers in this office. You basically had a session with every other designer once a week. Four out of five days you would have half an hour. Now at this point, we have 12 - 13 designers in this office. That becomes a little untenable. We kind of spread this out to the either every other week. Now we're thinking about moving it to every third week. You still have a regular rotation where you're meeting with people a couple of times a week. They'll just be kind of spread out.
The bulk of Slack overall is in San Francisco. I believe all but one of the PMs are here and the design team is actually heavily split between here and Vancouver. Almost all the people I work with in terms of the platform team are here. I'm really lucky that it gets really easy to do that. I know like I said the designers in Vancouver, for instance, there's a couple of core designers over there. Most of their team is over here. They do a lot more using Slack again to really communicate things regularly. They have a lot of Zoom meetings. I think that actually works out pretty well as long as you have designers who are really good at reaching out at just the right time. It does make it hard to really sit and collaborate quite as closely. It's definitely a challenge. I think having good communication and I think just the fact that we work on Slack and use it really intensely definitely helps a lot in that area.
Yes, so the platform team does actually have personas. They're not traditional personas in the way that you've collected a lot of data and then broken that into users, different sets of users, and then create an example persona for each one. The ones that are used on the platform are really to represent the very different users that we're serving. Then our research team is starting to think about some user segmentation for Slack overall. I don't know if they're going to go with personas but they're at least going to break it up. They're doing some pretty comprehensive research to see what those segments are. Then I think from there they'll figure out a way to communicate that across Slack as these are people that we should be thinking about and also help us have a shared vocabulary when we talk about users.
Get our best human insight resources delivered to your inbox every month. As a bonus, we'll send you our latest industry report, The rise of the Experience Economy!