Design is never neutral. It feels like the apps we use every day give us all the freedom and choice in the world, but that’s never actually the case. Every option, every button, every interaction defines not only the actions that we can take, but also the actions that we want to take.

Given the amount of space we give apps in our lives — in our work, our finances, our fitness, our entertainment, our social lives — the choices we make as designers have very real consequences.

When our remote team started using Slack three years ago, we experienced the subtle but real impact that design has on behavior. From its free-flowing chat channels to its one-line-at-a-time message composers, everything about Slack was designed to keep you communicating with your team in real-time, all the time. (It’s not surprising that the team behind Slack originally designed game apps).

Was constantly responding to group chat messages the best use of our time? Of course not. But that’s what we found ourselves doing.

We identified a need for a different kind of communication tool and set about designing Twist. (You can read more about that decision here.)

Twist’s design certainly isn’t neutral either. We set out to intentionally build a tool around the values we hold as a company:

• That the thoughtful conversations that push meaningful work forward are the lifeblood of a team.
• That to be transparent, conversations not only need to be accessible to everyone, they also need to be organized in a way so that people can actually go back and find them later.
• That people need to be able to disconnect to focus on their work — or enjoy life outside of their jobs or take a vacation — without feeling like they’re missing important conversations.
• That people should be able to work from any time zone in the world on the schedule that works best for them, without being left out of important discussions.
• That work should bring fulfilment, not stress and anxiety.

We wanted to give you a transparent look into the choices we made to design Twist around those values, the issues we faced and how we solved them, and the challenges we’re still facing. Whether you’re a designer interested in building more ethical principles into your own apps, or someone interested in learning about how Twist actually evolved, we hope you’ll learn something useful.

The 3 original requirements

When we started we didn’t have a concrete list of specs for our new application, but we did settle on 3 main requirements that guided the design from the beginning:

1. One tool for all the team communication

Until this point we were using Slack as a chat app, Wedoist (our old internal tool) for longer-term discussions, sometimes email for other conversations, direct messaging apps like Hangouts to quickly talk with others, Todoist’s shared projects for yet other internal messages, and more.

Too many communication tools made it impossible to focus.

This fragmented communication was making it impossible to know where each conversation was when we needed to reference it later. Things were missed and communication felt disorganized and stressful.

We needed to create an app capable of housing all of the different kinds of communication that happen at a company in one place without being overly complicated.

2. Mostly public communication

Transparency is central to the way we work at Doist. We know from experience that we can build a better company and better products faster if we don’t discuss things in isolation. For example, of the 50 or so Twist channels that we have, only two are completely private. As a remote company this level of transparency is paramount, but we believe that all teams can benefit from democratic, transparent, and inclusive conversations.

Whatever we built needed to ensure that the majority of information would be accessible to and searchable by everyone — particularly newcomers who aren’t aware of what’s already been discussed by the team.

3. Asynchronous communication

Technology has made real-time communication possible at a single click, but our team recognized the danger in being constantly connected. At Doist, we believe in ambition and balance. We prioritize time to disconnect, not only to enjoy life outside of work, but also to be able to do the deep work that moves important projects forward.

We also believe that the future of work is remote — where people from diverse backgrounds, countries, and time zones come together to build better products and companies. With team members spread across time zones, real-time communication just doesn’t work. If we wanted everyone to have a voice — no matter their location, time zone, or workstyle — we knew we couldn’t base the entire company communication on real-time chat.

We needed to go deeper and evolve the new product (and our company) into asynchronous communication. With our new tool, everyone needed to be able to communicate on their own schedule without missing anything important.

How did we turn three core requirements into a full-fledged app? The rest of this post outlines several of the key decisions we’ve made along the way to align the UX/UI design with our overall product and company vision.

Putting principles into practice

Chat vs Threads

The biggest issue we had with Slack was the chat structure where multiple topics are merged into one endless conversation. Not only was information quickly buried, but it also tied people to the app, constantly checking on new developments in a channel.

We quickly realized that older forms of digital communication — emails and forums — had actually avoided this specific problem (albeit while creating different issues of their own). Users can create a new topic/email for each conversation, give it a subject, and from that point on the discussion would stay organized and on-topic.

Conversations structured around specific topics might happen more slowly than in chat, but they ensure that important discussions don’t get buried or missed while someone is spending time with their kids or sleeping or focusing on other work. Threads make it easy to return to previous conversations later in the day, tomorrow, next week, next year, whenever.

In other words, placing threads at the core of the product would help teams keep conversations both transparent and asynchronous (two of our three original requirements).

Having solved our biggest UX design concern, we finally set out to create the first wireframes of the new app:

Early Twist layout design from May 2015 with focus on threads, no direct messages yet.

Unfortunately, we hadn’t quite solved our first requirement: all communication in one place.

Adding Direct Messages

Two years into product development, our team switched entirely from Slack to Twist. It was, admittedly, a rough transition. At that point, the only way to communicate in Twist was via thread.

Like we hypothesized, threads were great for discussing work. But that ineffable camaraderie that came with real-time chat was missing, and everyone on the team felt it. Some people tried using threads to “chat”, but it was like trying to fit a square peg in a round hole. It just didn’t fit with the interface. We knew that we had to solve this problem for ourselves if we had any hope of making Twist a viable alternative to group chat apps.

Soon after the switch, we decided to add some form of direct messaging to complement threads — something that would make communication feel lighter and more casual — without losing the simplicity of the app or the asynchronous nature of conversations.

We tested and discussed a lot of layouts internally…

Layout explorations trying to incorporate direct messaging into Twist.

… but in the end we opted to keep Messages and Threads as two entirely separate tabs within the app.

Focus on each type of communication in separate tabs.

We did this for a few key reasons that stem from being mindful of people’s attention:

1. Threads are meant for more complete thoughts and longer-term conversations. Messages are short and casual, used for quick check-ins or socializing. It stands to reason that people may be in different “modes” when they want to check on a thread or start a message. With two separate tabs for Messages and Threads, people can check on one without getting distracted by the other.

2. Because messages and threads are meant for two very different kinds of communication, they require very different UX/UI. On desktop, the message input is a simple one-line field that lets you send by pressing Enter. In contrast, the thread composer has a larger entry field, includes a markdown option for formatting, and requires you to click Post to submit. (Enter will start a new line.) With threads and messages in the same tab, the cognitive load of switching the composer UI and context was way too high. Keeping them in two separate tabs made the transition between the two modes of communication much more intuitive.

Comments and messages components

3. With messages in a separate tab, we had the space to comfortably display a snippet preview of a new message in a conversation before a user clicks through. It may seem like a small thing, but the snippet preview makes it possible for people to gauge the importance of a message at a glance and decide whether to answer now or later.

It’s easy to glance at a message or thread and see if it’s urgent or not.

While we’ve found that messages are an essential component of team communication, threads are the still the most important feature of Twist. In onboarding, we emphasize creating or contributing to a thread as the most important first action. Messages are secondary.

Mindful notifications

Notifications are the main UX tool designers use to keep people coming back to their apps. For any communication app, notifications are a necessary evil, but we wanted to make sure that people using Twist would maintain as much control as possible over when they communicate.

Choosing who to notify

Another huge drawback from a group chat design like Slack was that every new message in a channel triggered an unread notification for everyone in that channel. The result was a lot of irrelevant unreads cluttering up the interface and pulling us back into conversations we didn’t need to read. With threads, we wanted to create a more mindful system that minimized notifications for everyone.

We took what we learned from Todoist task comments as a starting point. Even though everyone in a shared project can see all task comments, you can select who specifically gets notified when you post a new one. We applied similar UX principles to newly created Twist threads and comments: everyone in a channel can see everything, but you choose who should be notified about any given thread or comment.

Unread dots without the numbers

Once someone’s notified someone about a new thread or comment, we needed a way to let them know that something relevant has been posted without pressuring them to check right away. The purpose of unreads in Twist is to indicate relevant activity users can check when they choose to, not to pull people back into the app.

Nobody needs the stress of seeing 99 unread messages

Many apps mark unreads with the number of items that need attention, but seeing an exact number can be overwhelming and create a subtle pressure to always stay at “inbox zero”. Instead, we opted to use a simple unread indicator dot without a specific number. Design-wise, we made the unread dot as subtle as possible and displayed them only on the main navigation tabs.

Prominent notification snooze

Once we solved notifications that trigger an unread inside the app, we turned our attention to the potentially much more distracting desktop, mobile, and email notifications that are sent when you’re not actually using the app.

We made the snoozing notifications menu easily accessible in the top-right corner on desktop no matter where you are in the app. People can turn off all notifications from Twist for up to 8 hours. You can also choose to schedule daily snoozing so you only receive notifications when you’re actually working.

Adding an option to set Days Off every week was a particularly important feature for our team. Disconnecting from work on the weekends is what keeps us fresh for the week to come. We wanted to help other teams set healthy work boundaries too.

Time Off

Time Off example on iOS

Too many employees feel like they have to stay connected during their vacations (which of course completely defeats the purpose of taking vacation). Beyond daily and weekly snoozing, we also wanted a robust feature that would set the expectation that you should not have to check your conversations while you’re on vacation. Or sick leave. Or parental leave. Or simply out of the office for an extended period of time.

When someone sets their “Time Off”, Twist turns off all notifications until the date you return. Your profile photo automatically changes to a Time Off avatar (which changes depending on the reason for your leave) and a message appears next to your name indicating why you’re gone and when you’ll return.

Displaying your Time Off status so prominently in the interface lets people know not to expect a response. If it’s urgent, they can find someone else to help. If it’s not time-sensitive, they can post a comment for you to check when you get back.

Asking for notification permission

Being mindful about your notifications is important to us

People expect to have the option to receive desktop notifications, so we knew we needed to integrate permissions early into the user experience. However, this was also completely at odds with our philosophy of fewer notifications and more focused work.

Instead of being pushy about turning on notifications like a lot of apps are, we added an understated grey message to the top of the app that appears after the first time a user gets a notification that concerns her and if the permissions on the browser are unknown, we display the mentioned banner. While the user doesn’t take action, we keep accumulating notifications to a limit of five. In case the user allows notifications, we will immediately display pending notification to the limit of one per type thread_added, comment_added or message_added. We kept the wording neutral so people could easily decide whether they want notifications or not. Once they’ve made a decision, we follow up with tooltips in the notification settings to let them know they can customize their notifications if they become too distracting.

This way, a potentially sticky onboarding moment becomes a natural moment for educating new users on how the app can help them control when and how they communicate with their team.

No “online presence”. No “read receipt” indicators.

Two hallmark features of most team communication apps are indicators letting people know if you’re online and indicators letting people know if you’ve seen a particular message. Both of these features create pressure to be available and respond immediately. They put other people in control of when they communicate with you. With Twist, we wanted to flip that on its head.

We removed the online presence and receipt indicators entirely. That said, we decided to keep the “Someone is typing…” indicator to avoid confusion when multiple people are online at the same time (we didn’t have this originally and it was a huge pain with people commenting over one another). When you see “someone is typing” you can take a moment to pause your writing and review the other person’s comment before posting yours. This keeps threads a little bit cleaner by avoiding multiple lines of similar comments.

The result is a UX that makes people feel more comfortable communicating asynchronously rather than responding immediately.

Choosing familiarity over novelty

Getting one person to adopt a new tool can be hard. Getting a whole team to adopt a new tool together all at the same time is, well, much harder. With that challenge in mind, we intentionally set out to maintain UX patterns that people are already familiar with, rather than invent new, unfamiliar ones.

We needed to make sure that the core experience of starting threaded conversations — investing time and information into the app — was as intuitive as possible. Any time we found ourselves wanting to add a tooltip, we took a step back to rethink the design and find a more obvious and simple solution.

For example, the current thread composer and the inbox concept that aggregates all a person’s relevant threads are both very similar to email. It would have been easy to let our egos get in the way and design something entirely unique, but our objective was to make it as easy as possible for teams to adopt the tool right off the bat. Twist isn’t reinventing the wheel but rather combining the most useful aspects of other tools into a single simple app.

Inbox with threads similar to email clients

Mobile and desktop first

These days mobile-first design isn’t just a nice-to-have. Users have become accustomed to beautifully designed, intuitive mobile apps, and they expect no less from the apps they use for work. We knew that we couldn’t create great design solutions for desktop and then try to force them to fit mobile. Design for all platforms needed to happen in tandem.

Over the course of creating Twist, we’ve developed a new design workflow to ensure that all features are optimized for both mobile and desktop at the same time. Each new feature gets a spec that lists out why we do it, what it will do and the use cases and edge cases for it. Then the designer includes the proposed UX/UI design for each native platform — web, macOS, iOS, and Android — along with all of the copy for each. Mock-ups and prototypes get updated as changes are suggested to the design so that everyone has access to the latest iteration. Here’s an example:

We use Dropbox Paper for our design documentation

With our new spec system, all platforms maintain feature parity, while intentional deviations in design or copy are made to follow platform-specific guidelines. For example, while both Android and iOS apps have the same iconography, their Settings are housed behind a “more” button in different locations. On Android it’s located in the navigation drawer, and on iOS it can be found in the bottom tab bar. This way, users will be familiar with both platforms on matter which device they’re using that day.

The goal is always for each app to feel completely at home on its platform, while making the transition from desktop to mobile and back smooth and intuitive.

Future challenges

The initial response from Twist users has confirmed our design hypotheses — that threads bring a sense of order, calm, and longevity to team communication that’s missing from group chat apps. But the product development process is just getting started. There are still a lot of key design challenges and tensions inside the app that we need to solve. Here are the biggest two:

Getting all team members to experience the value of threads.

Onboarding is an issue for any product, but the unique, longer-term payoff of holding conversations in Twist doesn’t do us any favors. New users naturally gravitate toward messages — the part of the app most like group chat — because it’s the easier paradigm to start using.

On the other hand, threads require you to think more deeply and communicate more thoughtfully about a particular topic. It can feel more formal and intimidating, and it’s not always clear to new users why they should use threads over messages. The “a-ha” moment is much less immediate than with group chat.

One user described how Twist clicked for him when he was able to go back to a thread and pick up where he left off a week later. That’s a long time between starting to use an app and being able to really experience its value. We have to design ways to get new users to understand and experience the value of Twist in a more condensed timeframe.

But onboarding is a small part of a much bigger challenge we’re facing…

Changing team cultures.

Most companies today still run on real-time communication — in meetings or chat or even email. They don’t make space for people to focus on deep work. Those teams are never going to understand the value of using Twist over Slack, or any of the other dozens of group chat apps out there, if they don’t recognize how disconnecting from work can make their employees healthier and more productive.

While Twist’s thread-centric design makes it much easier to collaborate asynchronously, teams can still use Twist in real-time like they’ve done in the past with email. If your boss expects you to respond immediately, you don’t have a choice. No matter how thoughtfully we design the app to be mindful of people’s attention, change also requires a shift in the mindset by both users and team leaders.

In building Twist, we realized that in-app design needs to be complemented with intentionally designed experiences outside the app — in our Help Center, on our blog, in our emails, on our social media channels, in our illustrations — that promote a more mindful, balanced approach to teamwork. Content design and app design need to go hand in hand.

Changing team cultures isn’t going to happen overnight, but we believe the companies that make this shift are the ones who will outperform the rest. Ultimately, we’re measuring the success of Twist’s design in the number of teams we help get there.

There was a lot more that went into Twist that we weren’t able to cover here. If you still have questions about the design process behind Twist, the design team is happy to answer them! Let us know in the comments below or on Twitter at @twistappteam.

Follow our design team on dribbble.com/twist and dribbble.com/todoist.

Ana is Head of Design at Doist, working on Twist and Todoist. Lover of food, travel and learning.

Alex is a Product Designer for Twist & Todoist. Into UI/UX, illustration, football, tech and productivity. dribbble.com/alexmuench