Overview
Context
Camelo is a shift scheduling and employee management app. Chat was well-used on mobile: teams relied on it to coordinate shifts, ask questions, and stay in sync. But the feature didn’t exist on web.
For managers, this created a constant context-switch. They spent most of their time on desktop planning schedules, but had to reach for their phone just to reply to a message, often mid-task. Several had asked for a web version directly.
Business need
Bring Chat to web to keep the experience consistent across platforms and reduce support requests about the missing feature.
User need
Let managers stay connected without leaving their desktop workflow.
How do we bring Chat to web without losing what made it work on mobile, and without overbuilding the first version?
Solution
I designed Chat for web: the same core experience as mobile, adapted for a larger screen, scoped to ship within a month.
Outcomes
73%
of mobile Chat users adopted Chat on web
68%
of active web users started using Chat
Research & Discovery
Understanding how teams communicated
Before designing, I wanted to understand how managers and employees were already communicating across devices.
Users were already living on both platforms
Analytics showed 73% of active mobile Chat users also logged into web weekly. Managers were the heaviest cross-device users, constantly switching between scheduling and messaging throughout the day.
Session recordings showed where mobile fell short. It handled quick updates and shift confirmations well, but broke down for longer conversations, searching older messages, or managing multiple chats while doing other work.
Desktop and mobile carry different expectations
The web version couldn’t just mirror mobile. Through usage analysis and competitor research, I found desktop users expected:
- Faster scanning across conversations
- A persistent conversation list
- Easier file sharing and message history
- Room to multitask while referencing other work
At the same time, familiarity mattered. Users already recognized the conversation structure, read states, message grouping, attachments, and reactions from mobile. These patterns needed to carry over so the feature felt continuous across devices.
Because Chat already existed on mobile, the challenge wasn't inventing a new messaging system. It was adapting it meaningfully for desktop communication patterns.
Competitive analysis
I looked at Connecteam, 7Shifts, Slack, and Homebase to understand how they handled layout and interaction.
Layouts varied — left sidebars, right panels, floating windows — but all of them kept chat and feed-style features as separate navigation items.
Interactions were consistent across all of them: hover to react, hover to see the sent time, open a message menu for more actions. Standard conventions users already know.
Process
Explorations & iterations
Since we were adapting an existing feature rather than building from scratch, the design questions were focused: layout, navigation, and which mobile interactions needed rethinking for desktop.
I tested interactive prototypes with users and teammates through unmoderated walkthroughs and internal reviews, and reviewed analytics and session recordings after launch.
Feedback was directional rather than statistical, but consistent enough to validate the core decisions.
Every idea and decision was grounded in two guiding principles:
01
Adapt while preserving the mental model
Keep the same mental model as mobile — conversations, read states, reactions — while adapting interactions to desktop behaviors and workflows.
02
Scope tightly, with extensibility in mind
Ship what already works on mobile before adding anything new.
Exploring different layouts
I started by auditing the mobile experience: which parts people relied on daily, which interactions felt natural, and what might break on a larger screen.
The team’s main concern was whether the left navigation sidebar and a left chat panel could sit side by side without cluttering the space. I explored four layout directions, each with its own trade-offs.
We agreed on a familiar layout: a left panel for conversations, with the rest of the space dedicated to the main thread. This kept room open to add a right panel later for conversation details or other options.
User testing surprised us. We worried the layout would feel dense, but users actually preferred it. They wanted constant visibility of the chat list so they could switch between conversations quickly. What we treated as a concern turned out to be exactly what users wanted.
Separating Chat and Team Boards
Team Boards is a structured posting and commenting feature, similar to a forum. On mobile, it lived alongside Chat inside the Inbox as tabs, so we considered the same approach on web.
But Team Boards is complex on its own — long posts, comments, threads. Grouping both under one Inbox blurred the distinction between real-time messages and structured posts, and made each harder to find.
We split them into separate navigation items. Each got its own page, and the mental model became clearer.
Separate page for Chat and Team Boards
Supporting better multitasking
On mobile, conversations usually happened in isolation. On desktop, users expected to reference other data while messaging.
Early fullscreen concepts reused existing app components, which forced users into a new tab to check a schedule or employee profile. Later iterations explored modals and slide-ins to keep users in context.
The modals required engineering work we couldn’t prioritize at the time, so we deferred them.
Users had to open the Calendar page as a separate page while using Chat. We prototyped a calendar modal, and users responded positively.
Staying within scope, with scalability in mind
There were plenty of nice things we could have added: message edits, more emoji options, thread replies, quick-actions on avatars.
But the constraint was clear. Ship what exists on mobile first, then refine. Extras on one platform create inconsistency and pressure to replicate on others.
The first version was still designed with scalability in mind. The layout already accounts for a right panel for conversation details, and the message structure leaves room for thread replies.
Final Design
Highlights of the final design
A layout built for scanning and multitasking
The final layout keeps a persistent conversation list on the left and the active thread on the right. This matches how managers actually work on desktop: keeping context visible while moving between conversations and other tasks.
Separate channels & direct messages
On mobile, all conversations live in a single list with no distinction between channels and direct messages. On web, I split them into separate sections in the left panel so it's easier to scan and tell the two apart at a glance.
Browse and add channels
Users can browse available channels and join the ones relevant to them. Channels can be set to private or public depending on their purposes.
Reactions
Hover a message to react. Emoji options match the ones available on mobile so reactions stay consistent across platforms.
Read receipts
Read receipts appear on hover or through the message menu, keeping the information accessible without cluttering the conversation view.
Impact
The results
One month after launch, Chat on web reached the audience it was built for. Managers had what they needed to stay in their scheduling workflow without switching devices.
73%
of mobile Chat users adopted Chat on web within 1 month
68%
of active web users started using Chat
Reflection
What I learned
Information density matters more on web.
Mobile chat is often single-column and minimal. On web, users scan more. They expect a visible conversation list, side panels for context, and easier navigation across multiple conversations.
Scoping tightly is a design decision, not a compromise.
Shipping parity first without extras kept the feature consistent across platforms. Every nice-to-have we held back was one less inconsistency to maintain, and deferring them kept the door open to implementing them properly later.