Design for Both Sides
When one product serves two kinds of user, the person who starts the work and the person who does it, every design decision has to be made once for each. Four lessons from two products built that way.
When one product serves two kinds of user, every design decision is made twice: once for the person who starts the work, and once for the person who does it.
A client portal has clients and staff; an approval flow has requesters and approvers. Each side wants something different from the same screens.
Chronologiq and RecommendMe are two AI products our founder, Shan Peiris, built before neesh Inc. The engineering below is theirs, and the numbers are his rather than a client’s.
RecommendMe serves requesters, who need recommendation letters, and recommenders, who write them. Chronologiq serves trackers, who log events, and analysts, who look for patterns in them. Building both taught four lessons.
Lesson 1: Keep both roles in one view when one person plays both
The first instinct is two dashboards. In RecommendMe, though, every user is both: the person who sends a request today receives one tomorrow, and two interfaces would mean a switch every time the role changes.
What they need to see
- Requests I’ve sent and their status
- Letters received and ready to download
- Credits remaining
What they need to see
- Requests I’ve received and how urgent they are
- Letters I’ve written and their status
- AI drafts available
RecommendMe shows both sides next to each other on a desktop and as tabs on a phone, so everything about your letters lives on one page. When both sides live in the same person, split the data inside one view.
Lesson 2: Charge the side that starts the process
In RecommendMe the requester pays credits to send a request, and the recommender drafts the letter with AI for free. The split is deliberate.
The requester pays
Credits to send a request, because they started it
The recommender pays nothing
AI drafting is free, because they do the favour
Both get what they came for
A letter for one, a finished draft for the other
The requester wants the letter and will pay for it. Charging the recommender for the tool that saves them an evening of writing would feel like a tax on a favour. Who pays is a design question: charge the side that starts the process and subsidize the side that does the work.
Lesson 3: Give each side a different kind of AI help
Wants AI to take work away
The tracker in Chronologiq pastes raw text and gets a timeline. The requester in RecommendMe fills in a short form. Both want the tedious part done for them.
Wants AI to show what they would miss
The analyst in Chronologiq gets statistically grounded findings across 500 events. The recommender in RecommendMe gets a draft pitched to the rating they gave. Both want a starting point to refine.
The same model can power both, but set the prompts, the screens and the amount of control for each side.
Lesson 4: Each side needs a different reason to trust it
The requester or tracker needs to see that the system received their input and is working on it: status updates and progress. Their worry is that their request went into a void. Trust for this side means seeing the process.
The recommender or analyst needs to shape the output: a preview before anything is final, editing, and the power to override the AI. Their worry is putting their name on something a machine wrote. Trust for this side means control over the result.
RecommendMe answers each worry separately. Requesters see a status on every request and get an email at each stage. Recommenders can edit, regenerate or discard the draft, and review it before anything is sent.
When to share a view, split it or subsidize a side
Who are the two sides of the system you are planning, and what does each need to trust it?
Book Free Assessment