How Slack built simplified layout mode for accessibility

Thank you so much for joining us. We know that the weather out there was a little treacherous, so we really appreciate those of you who make it in person. Thank you to our friends online as well. We're really excited to talk about how we built one of Slack's most unique accessibility features, Simplified Layout Mode.

A brief introduction. My name is Lena. I'm a software engineer on Slack's Design Systems and Accessibility team, and I use she, her pronouns. Okay.

I'm Kaili. I'm also one of the software engineers on the same team. And I'm Chris. I'm a product manager on the same team.

Before we jump in, I just want to take a quick poll. How many people have used Slack before? Awesome. Full room.

Keep your hand up if you've used it for work. Great. Well, part of our job as the accessibility team is to make sure that Slack works for everyone. So we do that in a number of ways.

So one of our roles is we build our own. So we build infrastructure and tools to raise Slack's accessibility ceiling and floor. So when we talk about raising the ceiling, we're unlocking support that we can give for assistive technologies or new ways for users to customize Slack to work for them. When we talk about raising the floor, we're talking about projects that make it easier for everyone else at Slack to develop without accessibility regressions.

We also partner with teams across Slack throughout their development process to ensure their features are inclusively designed and accessible at launch. And we provide all sorts of support and guidance for that. And despite our best efforts, things do slip through the cracks. So we also work on patching accessibility bugs and doing our best to prevent new ones.

Well, it seems like most of you are pretty familiar with Slack. But for those who aren't, Slack is a collaboration platform where teams can communicate through messages, calls, shared files, and more. It's a place where you can really have those important conversations alongside the work that you do. And these interactions can take places in channels, direct messages, group DMs as well.

And just to give you a quick overview of the main surface areas, we have the workspace switcher, which is in the top left. And if you hover over it, you get a list of all the teams or what we call workspaces that you're in. We also have the tab rail. So this is a thin...

vertical column that contains a series of icons. And it contains essentially navigation buttons that bring you to some of the main surfaces of Slack. So currently we're on the home where you can access the channel list. There's also DMs for direct messages, activity for all your notifications, and files for canvases, lists, etc.

that you share... that are shared with you or that you have written. So going back to our home view, we have a multi-column layout. So the first column is the channel list, which is essentially a list of all the conversations that you're a part of.

And then on the right of that column, we have another surface, which is our message list. And so this is the actual conversation that you are participating in. And we also have something called threads. So a thread is essentially a group of messages that are linked to a single message in a main conversation.

And we have those to kind of keep clutter out of the main conversation. But what that does is when you open a thread, it opens in yet another vertical column, what we call a flex pane. So as you can see, there's quite a lot going on. We have three distinct columns, each independently scrollable, as well as the main navigation tab rail on the left.

And you might imagine for new users, people unfamiliar with Slack, or people who use assistive technology, eye tracking software, et cetera. This can be a lot to deal with. So our solution to that is our feature, simplified layout mode. And Simplified Layout Mode is a complete new approach to Slack's interface with larger click targets, buttons that don't rely on hover, and a dramatically simplified layout that shows only one of these content views at a time.

It's designed specifically for users who are using eye tracking or head mouse technology, but it's useful. It's useful for anyone who really just wants a cleaner, less noisy experience. Now, as for how you can turn this on, what you do is you enter our preferences modal, go down to our accessibility section, and it's actually the first feature. So we hit turn on, and, wow, very, very different, as you can see.

So what you're currently looking at is our main landing page. And what we've done is, if you remember that tab rail, on the very, very left of our default client interface that had all of those main navigation buttons, we've blown those up into its own page. And so here you can also navigate to any of the surfaces that you were seeing just before. So home, there's DMs, activity, et cetera.

The workspace switcher is also here, but instead of being a menu that hovers, above the rest of your client, it's also its own view. And let's just go into home, see what that looks like. So this is our channel list. So if you recall the three column layout that we were showing previously, this was the first of three columns.

And as you can see, there's much more surface area to work with, because instead of having it constrained to one third of the screen, we have it taking up the whole view. And so you can jump into one of the channels to see what that looks like. And this is our message list. Once again, common theme, its own view.

And if you actually want to go into a thread, instead of it opening in a flex pane on the right, it's also its own view. And so one of the things that I do want to quickly highlight is the message actions. So these are kind of, as the name suggests, actions that you can perform on a message. So you can add a reaction, start a thread, et cetera.

And in the default view of Slack, these are all hidden behind hover. So you need to actually move your cursor over the message and hover over it, and a thin horizontal bar will appear, and you need to chase that down and then perform the action that you're trying to execute. So what we've done instead is we've created a preference where you can actually put your message actions behind this button. And once you click, it opens a persistent menu, which makes it much easier for users of assistive technology, such as eye tracking software, to access those.

Another preference that we've made as part of this project is zoom level. So you can set your own custom zoom level for Simplified Layout Mode that is distinct from your zoom level in your regular client. And so this is very useful for users who want to toggle between the two and persist, you know, different levels of zoom between the different modes of work. And then the last thing that I wanted to call out, I did use this very briefly in the beginning, but just want to explicitly show you, we have this thing called the breadcrumbs bar.

And essentially what it does is it gives you easy access to previous parts of your navigation stack. Since, you know, previously we had everything that you needed laid out on one screen versus now we've split it out into separate views, it can get a little bit unwieldy to move between all of them. And so what we've done is we've created this breadcrumbs bar so you can easily jump back to, say, home or the main landing page.

And then you can quickly exit Simplified Layout Mode with this button.

All right. Thank you, Lena. Now that you've seen a little bit about what Simplified Layout Mode is, I want to take you through a little bit of the journey that we took to get here. So the story started when a employee resource group at Salesforce, which owns Slack, reached out to us because they wanted to create a global community for people who are patients or caregivers with ALS.

And they wanted to build that on Slack. When they reached out to us, what they were curious about was, before committing to the platform, they wanted to know how accessible is Slack for people who are using eye tracking technology because ALS is a neurodegenerative disease and people in later stages of the disease often have to use eye tracking to communicate or to operate technology. And we thought that was a really interesting question.

So we dug in. When we... Our team had been around for quite some time at that point, but we had actually heard very little from eye tracking users. So we kind of threw ourselves into learning as much as we could about the technology, talking with people who are using the technology, and partnering with our research vendor, Fable, to actually interview people who are eye tracking and head mouse users.

And what we learned was that Slack was generally usable, but that there were a few challenges that made it more difficult than it needed to be. First, our interface is, as Lena showed, pretty densely packed, full of little tiny buttons, and that requires a lot of precision, which is very fatiguing. We also hid a lot of things behind hover so that we didn't clutter up the visual interface too much, but those are extremely difficult interactions when you're using either of those technologies.

And the multi-column layout, combined with not very, very much true empty space in the interface, made it a little bit tricky to scroll an individual container. So we set out to sort of imagine what would it look like to try to design a version of Slack that worked better for these technologies. And based on the research, we came up with a couple of guiding principles. First, this new version of Slack would have to be ergonomic.

We wanted interactive targets in easy-to-reach and predictable locations. It would need to be a lot more sparse than it currently was. We settled on 40x40 tap targets with plenty of space in between. We wanted all the affordances to be visible and not hidden by hover interactions to not add that layer of work.

But we also still wanted it to be Slack. We wanted it to look familiar. We didn't want people to have to learn a new interface. And most importantly to us, we wanted to make sure this had feature parity with the main client because we didn't want to build a limited view.

So we got to work building what we were code-naming at the time Big Button Mode. And you can see these are some of our very, very early design explorations. This was a very exciting time for our team because our team at that point had spent most of our time fixing pretty subtle screen reader issues or keyboard navigation things. And so this was one of our first cracks at really doing a wild design.

So we went wild. We reimagined what the Slack landing page would look like with just a couple of main portals. In this version, there's a search bar at the top and then four very big buttons that took you to the workspace switcher, your channels, your DMs, and the ability to start a huddle and then a few auxiliary settings and things like that. We played around with all kinds of treatments for how to transpose the message composer that we have into a set of buttons that made it easier to share files and also transform the message actions from something that was hovering into a more button-based approach.

At the same time, we were also working on engineering feasibility for what we wanted to build because we knew that we were not going to be able to redesign Slack for literally everybody. And we knew that what we wanted to build needed to live peacefully alongside the main content. And we knew that we wanted to build something and, most importantly for us, actually be maintainable. If we built something that slipped out of parity because we're constantly shipping new features, that wouldn't be very useful for the team and it'd be very stressful for us.

So we really quickly realized that the best way to do that was to actually creatively work with what we already had on the page rather than truly start over from a design perspective. What if we just took the layout that we had, but kind of break it out into those single column views so that there was less to deal with at one time? So what you can see here is the first working prototype of Simplified Layout Mode.

It looks very similar to what we shipped ultimately, but there are a lot of things that changed along the way. So we spent a little bit of time polishing this until we got it to a point where we felt like we had a minimum viable product that we were happy with. What you can see here is that that last set of explorations has been polished. The corners are a little bit more radiused.

You know, the buttons look a little bit nicer. Thank goodness for designers. And at that point, we felt like we were ready to test it, dog food it ourselves, but also to put it in the hands of real users. And so began our pretty long user testing journey for this project.

The first group of people we tested with was the ALStogether workspace. So that was the community that kicked this whole thing off in the first place. We timed our development schedule so that they would have the very, very first version of Simplified Layout Mode available at launch for everyone who joined. And we heard not very much.

And what we realized was that it was kind of the wrong time to be asking for user feedback, right? There were a ton of people joining this new community. They were excited to talk to each other. They didn't really want to dive into the details of UX feedback with us, which is totally fine.

It was also a lot of people who were new to using Slack. And so if they were using Simplified Layout Mode, that was all they knew. And so they didn't have a ton to compare it to. And so again, not a ton of feedback.

So, you know, we sort of chalked it up to, okay, no news is good news. Let's move on. We then did a second round of feedback with Fable. So here we focused on basic Slack flows.

And we tried to get feedback from eye tracking and head mouse users, of course, our target demographic. We also strive to get feedback from screen magnification and screen reader users, because this is a group that we had hypothesized would also find some improvement in their Slack experience using Simplified Layout Mode. And so takeaways from this, the first was that Simplified Layout Mode did seem to significantly improve navigation for eye tracking and head mouse users, which is great news.

It was exactly what we wanted. In terms of screen reader users, it also seemed to bring a lot of improvements despite a couple obstacles. Screen reader users found that Simplified Layout Mode provided more consistent navigation. The client seemed more responsive.

And because there's less things on the screen, there's just generally less to keep track of. It, however, was amiss with screen magnification users who felt that the changes we had made to the layout sort of clashed with their own tooling. So based on this, we made a variety of changes, one of which was adding more specific onboarding. We realized that the things that we had built out specifically for Simplified Layout Mode were not very obvious to the people that we built them for.

And so this screen shows two of the steps within the modal, which surfaced the zoom levels specific to Simplified Layout Mode, which Lena touched on, as well as the message actions that let you either have them persist all the time or hide them behind a hover like standard Slack.

So next, because our team spent so much time thinking about improving the screen reader experience, we were really eager to dig into the gains there. So we ran an ongoing pilot with Prime Access Consulting, who are our very long-time and long-suffering accessibility consultants, and they have a couple of power screen reader users on staff. So this looked like a couple of rounds of live discussion as well as lots and lots and lots of async feedback.

And what we learned along the way was, again, confirming those Fable findings, having less stuff on the screen made it much easier to navigate, much easier for screen reader users to orient themselves. And again, it felt more responsive. We did have a lot of work that we needed to do to make the, on the navigation and orientation side, however, to make this mode self-sufficient. So what we were hearing was that people wanted to live in this mode all the time and they couldn't yet, but that was our next goal.

So one of those big outcomes from that round of discussions was the breadcrumbs that Lena demoed earlier. So having these breadcrumbs allows for a really consistent place to be able to go to always know exactly where you are in the navigation stack. We had originally hypothesized that people would be okay, you know, going all the way back to square one on that main page or just using the search to jump to an original channel.

And what we learned from people kind of living in the prototype was that having this navigation representation was really helpful for jumping into some of the more of the intermediate steps. It also gave us a nice affordance to be able to surface things like notifications. So that instead of just knowing that someone wanted your attention somewhere else in the app, we could give you a little bit more granularity around like this is where that is coming from.

So from using Simplified Layout Mode ourselves, we also realized that it might be helpful for non-assistive tech users. And so we tested this hypothesis internally a bit. First, we encouraged Slack co-workers to try this out. This is something that we did during Focus Week.

Focus Week is something that we have once a quarter where regular meetings are canceled and folks are just encouraged to do heads down work or more one-on-one collaboration. During this time, we also piloted with Salesforce's Neuroforce employee group, and this consists of neurodiverse folks. And so here we found that it was very helpful for reducing overwhelm, specifically for users with ADHD and dyslexia. We also heard from users that it was helpful in short-term, short sprints.

So if somebody needed to spend some time just writing up a document, really didn't want any distractions, it was helpful to have notifications in one place less loud and be able to do that focus work. And lastly, this round of feedback was especially helpful to us in surfacing some friction around feature-specific workflows and too much white space in certain areas. So we made a lot of design changes based on this. The first of which is max width.

So as we covered previously, we took the message list which has the messages in the threads and we blew that up to be the entirety of the view. And for people who have wider screens or for this example where you can see that people are sending relatively short messages, you have your message on the very left-hand side, but then the associated message actions are all the way on the right. And so that means users are scanning with their eyes across the entirety of the screen to get to where they need to.

And there's sort of this like false sense of white space where you would think that there's nothing on the right hand side, And so to address that, we confined the column and made it much more narrow and centered it so that all of your interactive controls are in the middle of the screen and you have genuine and more intentional white space on either ends that you don't need to worry about. And of course, users don't have to scan as much to get from the message to the controls that they want to change associated with that.

Another big style change we made at this stage was redesigning the channel list. So as you saw, the channel list typically is one of the leftmost columns in standard Slack. And because of this, it was built to be relatively small. All the helpful content, all of the channel names are on the left-hand side.

And when we blew this up to be the entirety of the view, you have a lot of space on the right-hand side. And so this causes issues with density and also because the layout is so different. It was quite jarring for users to go from the views that we had previously showed you to something like this. And so to address this, we applied the same max width that we had applied to the rest of the client and we changed the styling of the channels to make them more pillow like, more similar to what you saw in the main view.

And this made the click targets more defined and also made the page a lot less dense.

Now we want to share some feedback that we received from real users of Simplified Layout Mode. So James, an engineering manager, shared with us, I really enjoyed using Simplified Layout Mode when I had plans to be heads down on something for a while. It felt easier to scan what might need attention, and there was a lot less overwhelm than I'd usually have. Meg, a product designer, said, It has significantly cut down on the time I spend going through my Later tab, which I treat as an inbox.

I had no idea just how distracted I was seeing everything at once. Darrell, with customer success, said, I love Simplified Layout Mode. It provides consistent navigation for me as a screen reader user. No more fumbling around trying to figure out which sidebar is opened or closed.

Simplified Mode has greatly improved my relationship with Slack. And Eryn in Workplace Services said, I'm a big fan, and as long as Simplified Layout Mode is available, I will choose to use it. I only switched to standard Slack once, and that was because I was screen sharing and it confused my co-worker. As for usage, our analytics told us that, on average, there are 1,100 users opening Slack in Simplified Layout Mode per week.

And the median session duration for users is 8 hours, which means that half of people that use Simplified Layout Mode use it for at least 8 hours at a time. So now to project takeaways. We learned a lot from this project because it wasn't sort of our typical project that we work on. The first is this.

Maintainability as a constraint. Maintainability is something we had to keep in mind throughout the entirety of the project and really influenced design possibilities. Our team is relatively small compared to the rest of the Slack engineering org. And so we had to build something that would sort of grow and evolve as the main client did.

So far, it's been about two years since we fully released, and we found that it has been fairly resilient. The things that we have had to change have been like bigger architectural changes, where we did expect to have to change things in Simplified Layout mode as well, or changes made to custom views. So for example, anything with the top navigation, which we had built custom for Simplified Layout mode, or some of the home and workspace switcher views.

The next is the curb cut effect. So as we shared, this was originally built for eye tracking and head mouse users. And despite that, we found that it was also a big improvement for screen reader, ADHD, and dyslexic users as well. This is great news to us.

But it also meant learning to sort of balance wanting to expand our feature to work for everyone, while also keeping its scope and making sure that any sort of design decisions we made were not contradictory to our original target user group. This is also a piece of the maintainability puzzle as well, because the more people we have using it, the more users we have giving us feedback, reporting bugs, and the more people that are invested in keeping Simplified Layout Mode running as it should be.

The last big takeaway for us was building empathy for product engineers. So as we covered earlier in the slides, a lot of our work is working with feature engineers to make sure that the things they build are shipped accessibly. And working on this project allowed us to better understand the process that they go through when they're building their features and understand some of the challenges that come up there. So two of those may be that projects are consistently changing directions, so it can be really hard to know when to focus on accessibility.

Sometimes teams will come to us and they will take the time and really figure out the accessibility and then the project goes in a whole new direction. They have to figure it out again. And so that can be really tricky. Another is that when you're building out a feature, you don't always know how it's going to fit in the overall interface.

So that can make something like semantics quite difficult to sort out. We wanted to give a big shout out to the rest of the team behind Simplified Layout Mode. This took a lot of people in a lot of different roles to pull together. And also a big shout out to the content design team.

And everyone who gave us feedback really guided us in the right direction. In terms of connecting with us, we have the Slack community workspace. This is a public workspace where people that build on top of Slack, people that are just interested in tips and tricks on Slack are. And we have a channel within that called Slack Accessibility, which was demoed earlier.

Within there, we send updates. People are also very welcome to send us bug reports and feedback. There's always somebody from our team monitoring that channel, so you will hear from us directly. And you can join that at bit.ly, B-I-T dot L-Y slash Slack community workspace.

We also have an accessibility changelog. This is an initiative that was originally introduced in the Slack community workspace. And then we recently brought it to a more public page. And on this page, you will get monthly updates on what we've been up to, our latest accessibility releases, improvements, bug fixes, and much more.

And that's at slack.com/accessibility/changelog. And that is sort of in hopes of providing more transparency into the things we're working on and to let users know that we really do appreciate when you all write in. And one last announcement. We will very excitingly be hiring an engineering manager for our team very soon.

The job description is not up yet. But if you are interested, please reach out to us on the Internet somewhere. We would love to see your application. Thank you.

Nope. One, two, three. All right. All right, thank you so much.

We are going to do our audience questions now. I'm going to take a question online and then audience here. And so alternate. And we have our first question online.

It's is it possible to switch to using the kebab menu outside of simplified mode? Is it possible to switch to using the kebab menu outside of simplified mode? Right now, no. But we'll think about it.

Thank you. It was a great presentation. And one comment from the user feedback session really caught my eyes. There was a user mentioning that the only time he turned off simplified mode was because the simplified mode was not... freaks his co-workers out.

So I was wondering going forward, if there's two modes, like simplified mode and not simplified mode, could there be like a design gap so that if a team members that some have simplified mode and some doesn't have, will there be some communication gaps between them? And do you guys have some ideas going forward for that? I would love to hear.

Okay. Yeah, it's a good question. I think we tried to make the two as similar as possible. But I think it is true that you know, if somebody is like, this button is on the left side of the screen, and they're in this mode, because this mode is opt in, I think that most people are at least aware that they're in the mode.

So I think it helps clarify that relationship a little bit. And we did make it easy to kind of toggle in and out of the mode. So we expect that that will be a way that people kind of learn about both modes. But it is a challenge.

And I think in some ways, I think we made this bet that Slack was going to allow itself to be more and more customizable. And that has been true. So this is one of many ways in which two Slack workspaces can look different for people these days.

Bravo, bravo, bravo. I always look at accessibility and call it the capital. A is so much to chew when it comes to accessibility. You mentioned about the takeaway with the accessibility team.

Do you have certain disciplines that focus on vision, hearing, cognitive? Or is the team expected to know it all? Or if you have a hybrid? Or do you have an expert in each of those challenge types?

Marietta Robinson I would say a aerial teacher or virtual teacher. I would say our team definitely relies on user research and really hearing from people with different disabilities to do that. I would say that I feel like as the years, as the quarters go on, our focus seems to go in different directions and a lot of that has to do with like where user feedback comes from, where we're getting different pushes.

Is there anything you would add, Chris? Yeah, I think, as Kaili said, it's been a little opportunistic. Like to most directly answer your question, we are one team, we don't have specialties in these different areas. But for example, when Slack started introducing video chat and audio and video clips during the pandemic, that was the first time that anyone at Slack had to consider accessibility for audio because we previously just didn't have any other than that sound that traumatizes everybody in their sleep, which you can turn off if you want.

Yeah, it's very easy to turn off. So I think that, as Kaili said, we do basically try to do it all as a team, but rely on the experts when we get into places where we feel like we have less familiarity.

Hi, thanks for the presentation. I know most of your presentation kind of revolved around redesign of sort of the web interface for the Simplified Layout Mode. I'm curious sort of what influences from mobile did you guys get? Yeah.

So, and whether you took your learnings to, you know, any designers or any teams sort of working on the Slack mobile apps. So, like, I know the desktop is quite cluttered in the regular mode, but in the mobile app, it obviously is like already kind of a little bit more simplified, given the smaller screen. Yeah, for sure. I think we, we looked into whether we should expand this effort to mobile as well.

And actually, what we found was that we didn't really need to. And you can kind of see... It's not one-to-one, but in the design principles of where we landed for Simplified Layout Mode, it actually architecturally is pretty similar to how mobile works. Like mobile has a full view for home, for example, or for DMs, you can choose the DM and then it opens the view.

So in some ways, we kind of built a version with the Slack mobile app for desktop. So what would you say are the differences between like, oh, you couldn't just take on the mobile interface and just sort of present that as like the Simplified Layout Mode. Like in what places did you feel, oh, we still, you still needed to make changes or add additional screens or make, you know, make it for web slash desktop that it wasn't like a complete translation of mobile?

The code base is very different. We couldn't start from a mobile place, basically. Yeah, so Simplified Layout Mode has all of the affordances that are available on desktop.

I'm curious about the marketing about this so your users could learn about it. Like what's the thought process or like the mechanics, especially knowing people are using assistive technology, you want them especially to know about it. How did that work? I can, sorry for answering all.

a lot of questions. I can take this one, too. It was my responsibility. I honestly feel like this is one area of the project where we could have done more.

I think we We, we put out. I think the Simplified Layout Mode launched shortly before Global Accessibility Awareness Day that year. And so we you know, put out an announcement through Slack social media. That way we went to some of the usual communities where we get a lot of feedback.

So there's the web a11y Slack workspace, if any of you are familiar, and posted announcements there and things like that, but I am very interested in other ways we could be marketing some of our accessibility features. So, if anyone has any ideas, please let me know. I think there were some questions on the left side.

Great presentation. I'm a designer, so we work with engineering a lot and we know it's always up and down. I'm curious, how long did this take you from start to finish? And what was the most difficult thing for you to actually build?

I think start to finish, this took us maybe two years with some breaks, because oftentimes we would build, release to a certain user group, and then leave it there, collect feedback while we're working on other things, and then sort of circle back around. Ironically, the hardest thing I do think was colors. Slack has a very complicated sort of like color math going on between colors. Between your sidebars and your main pages.

I think another thing that was difficult was that there are quite a few things that I would say exist in the code base that are not very obvious to designers and are not surface to designers within Figma. And so, I think it took a lot of communication, a lot of back and forth there to get those ironed out. And our designer, Katherine and Andrew, they were very patient with us. About the colors, I know you have themes within Slack.

Does the Simplified Layout Mode work with the themes? Yeah. So, we're the accessibility team. We're also the design system team.

And so, we own the colors now. And so, it does work across all of the different themes, whether you have light mode, dark mode, light, dark, sidebars. It should work in all of them.

Thank you for the presentation. I was curious about an obnoxiously tactical detail. What went into the decision making, the thinking behind setting the... minimum hit state of 40 by 40 as opposed to something more conventional like 44 or 48?

That's a good question. I feel like one of our designers came up with that. And I don't know their reasoning behind it. But we just went with it.

All right. We got another online question. You said the design team learned more about engineering. What were some of the aha moments that occurred from the engineering team collaboration?

Design learnings. I would say just for the colors thing, like how complicated that was and where that was. And also, I think it surfaced some gaps in our design system as well. Like the fact that it was not very obvious to designers that we were going to run into these issues is something that our team should fix.

And so, I think that was one big learning. In terms of... I think for Figma, that was probably our biggest one. Yeah.

Is there any you would add?

Hello, ladies of Slack. It's really cool to see ladies presenting on really cool technology in a male-dominated world. So, thank you for the great work you're doing. Yes.

That deserves a round of applause. So, you asked about ideas. I've actually... Because I've been to the Salesforce trade show that you guys do at Javits for the last couple of years.

And I've never seen anything on accessibility. So, that's a missed opportunity to promote the accessibility stuff. Whether it's a panel, even just being plugged into the keynote, which a lot of people tune into. That would be a great opportunity for people to discover.

Because I've actually... You know, up until this talk, I didn't realize it was an accessible mode or whatnot. Two of my organizations use it. All right.

So, my question is, you know, the biggest challenge with user-informed design is that people tend to design for themselves. You know, you mentioned the neurodiverse group. Do you actually have neurodivergent people? Do you have people building these tool sets or designing these things?

Because oftentimes, you'll get a huge difference in what actually gets developed compared to when it's people that are designing with that feedback in mind. Yeah. Good question. I identify as neurodivergent.

But I have also learned from working with Salesforce's neurodiverse employee group that, you know, it's called neurodiversity for a reason. Everybody has a completely different opinion about what they want. We did have users who identified as having ADHD reach out to us and say, this actually makes things much worse because I want to see everything all at once. Like, that's how I sort of keep my brain calm.

And, you know, also other people who are like, please remove the notification badges so that I don't know anything about what's happening in the outside world so that I can focus. And that's true not just of the neurodivergent community, but also with every other type of design. And I think that's kind of the responsibility we work with. We, I would say, like, deal with very complex debates within the screen reader community very frequently about what they think the Slack interface should work and behave as.

So the short answer is yes. But I think this is where user feedback is really, really important and working and kind of co-designing with those users. When we were piloting, we weren't just sort of like throwing this feature at people. And then asking them for a survey at the end.

You know, we were welcoming them to give us feedback as they were living in it on the first day, on the fifth day, on the, you know, a week out before we actually asked them for their full opinion. So I think, like, being able to form those relationships and have a situation where people trust us enough to tell us their true opinion about what we were building was really helpful. And allowed us to kind of accommodate for the widest range of possibilities.

I've got five of my own. I will limit myself to one. And then we've got another one online that I'll read. And then I'll go to Aaron here.

And then we'll continue on from there. So you talked about your approach to maintainability and resilience to change and things like that. Are there still... I know you talked about how some of the top nav aspects change.

It's required a re-architecture.

How in sync do you have to be if a new component, let's say, is launched that's not accounted for within, I guess, being part of the design system team, you probably know that that's coming to some degree. So you have a bit of a cheat sheet, I guess, to think about how does that apply to a simplified layout. So maybe with that piece of information, you don't have as many surprises. But I'm curious.

Are there still areas where you feel like you're having to kind of... chase a moving train to keep that feature parity in sync? Or do you feel like kind of architecturally you're pretty confident? Yeah, I would say there are like very specific areas.

So if we go back to the demo that Lena did, like we can point out every single feature that was build custom to this. And I would say there's maybe a total of about five. You've got workspace switcher, the main tab rail, the more tab rail, which is an extension of the main tab rail, and then the top navigation. And then breadcrumbs, of course.

But everything else is just regular Slack in a different view, which means anything that feature engineers build within regular Slack will be piped over. I think where we are running into issues, one thing that we had recently is Slack released a focus mode. And you can turn this on from the bottom of the left tab rail near where you're like user and preferences are. And the way that they had implemented this was using something called peeks.

And peeks is something that we have turned off for Simplified Layout Mode. And so it's things like this in the areas that we know we replaced where it is harder to surface some of these. And I think with that, we had to go to the team and be like, hey, would it be possible to rebuild this with a different component so that we can surface it in Simplified Layout Mode? Can we think about what this is going to look like?

Like some of the changes that they had made to notifications, how can we replicate those in our breadcrumbs? And so a lot of the things that we are chasing are with the things that we have custom. And for the most part, people are not touching those quite as much, I would say, because they're sort of they've become what people know as slack. Like people are used to the tab rail.

They're used to those things staying relatively consistent. So I think the online question is very related. I'll read it in full, but I think you've answered a good chunk of it. Can you share more about how you made simplified layout mode able to adapt to changes from other engineering teams?

Any learnings or tips as you rolled that out? Anything else you'd highlight from kind of a planning standpoint? One thing that I was just reminded of right now that we didn't point out in the presentation is to go back to that idea of, you know, things really become more maintainable when more people are invested in their maintenance. One great example of that, I think, is that the breadcrumbs themselves are pulling from the accessible labels of all of the Vue containers, right?

So then it's like, if we mess that up, we're also going to have a problem. We're also messing something else up and vice versa. And so it's like a screen reader user can tell us that those are missing or, you know, we can detect that in our testing for that and know that that breadcrumb will be messed up or vice versa. So I think along the development process, we really try to find places where it's like, how can we make this, you know, a win-win for multiple teams or a problem for multiple teams at the same time so that when something goes down, we hear about it from multiple directions.

Cool. Aaron. Hi. It's been a few years since I was, you know, working in an environment that uses Slack as a standard.

So unfortunately, I completely missed this feature because I would love to use it all the time if Slack was my environment and maybe one day it will be again. I couldn't help thinking that about your F6 circumnavigation, you know, keyboard, you know, command. And it makes perfect sense that, you know... Keyboard-only users, screen reader users would potentially prefer this because you can drill down in more of like a traditional web standard way, you know, like your file system, you know, tree structure, you know, exactly where you're going rather than like, okay, I have to hop through a few things to get where I want to be.

So in this new mode, is that F6 circumnavigation still in effect? Like I'm down in the body and I want to get up to the breadcrumbs. Is there a dedicated key command to get to the breadcrumbs? Or would I use F6?

How did you guys do that? Yeah, we kept all of the F6 navigation, all of the regular tab navigation that you're used to within the main client within the message list. Those are consistent as well. The nice plus is you have less F6 stops that go around.

So I think there's only two or three in simplified layout mode compared to your a little less than 10 and out of standard Slack or in standard Slack. Never. If I remember correctly, we did actually have a conversation. About like, should we just get rid of it altogether in Simplified Layout Mode?

And what we realized were this is since you are bringing ball knowledge to us. We'll return the favor. F6 navigation is required for getting into and out of canvas because it's this like big editable content blob. And so you can't tab in it because it just inserts indentations.

So because of that and because of one other feature that uses a similar navigation paradigm. We kept it in. But I will say that one thing that was really exciting to hear for us was that one like existential struggle. We're constantly having especially with screen reader users is like, are you in focus mode or are you in virtual browser mode?

Because the experience is very different when navigating around Slack and we try our best to keep people in forms mode or in focus mode as much as possible. What we learned was that in Simplified Layout Mode. If you were in the other mode, it was fine because there just wasn't that much space you could get lost in. And that was really transformative for a lot of the users.

Thank you so much for this. It really makes me want to use Slack again. We have like one or two more minutes for a very short question.

Hi, ladies. Thank you so much. That was super exciting and informative. Just wanted to follow up on that colorist question.

Do you guys take into account like different kinds of colorblindness? Throughout Slack, we generally don't rely on color as a way to relay information. But Slack also has a number of colorblind friendly specific themes. So the default theme is that purple, which we call aubergine that you see.

But there's a number of themes and some of them are designed for specific types of colorblindness.

Very cool. Thank you so much. All right. I think we're going to wrap up the Q&A.

But we still have time after this. So you can also ask questions more one on one. All right. Thank you so much.