A dashboard has an awkward job. On somebody’s first day, it needs to explain what the product is, where to begin and what might be worth trying. A few months later, that same person probably does not want an explanation at all. They want to see what is happening, get to the thing they came for and carry on with their day. Those are two quite different experiences.
Until recently, Emily’s home page was trying to serve both with essentially the same answer.
It showed useful information. You could see activity, get into different parts of the product and understand some of what Emily had been doing. But as Emily itself grew, the weakness in that approach became more obvious. Email was no longer the whole product. Emily could arrange meetings, remember people, run automations, deliver briefings, store useful files, work over text and increasingly follow users into tools such as ChatGPT and Claude.
The problem was not that those features were hidden in the technical sense. They were there. The problem was that people still had to know to look for them. That led us to rethink what the home page was actually for.
Rather than building a better menu of everything Emily can do, we wanted to build a page that understood roughly where somebody was in their relationship with the product and helped with whatever came next. It looks like a dashboard redesign. In practice, it became an exercise in onboarding, product education, progressive disclosure and one surprisingly difficult question: how much should a product teach you before it gets out of the way?
The home page is part of the product
It is easy to think of a dashboard home as navigation with some statistics on top. That is usually how they start. A greeting, a few cards, recent activity, some shortcuts, perhaps a chart. Enough to reassure somebody that they have arrived in the right place before they head somewhere more useful. But the home page is also one of the few parts of a product that almost everybody sees repeatedly. That gives it an unusual role.
For a new user, it can explain the product without forcing them through a tutorial. For someone returning after a few weeks, it can remind them what exists. For an experienced user, it can surface the few things that are still useful without forcing them to walk past the same onboarding content for the hundredth time. Emily makes this slightly more complicated because much of the product is deliberately invisible.
You do not need to open the dashboard to email her. If she is handling an automation in the background, the dashboard is not where the work happens. If you text her, use her through ChatGPT or hand something over from Claude, you may only visit Emily’s own interface occasionally.
That is good. An assistant should not require constant administration. But it also means the dashboard has to explain a growing product without becoming the thing the product revolves around. We started thinking of the home less as a control centre and more as a guide. Not a guide that permanently occupies half the page. One that knows when to stop talking.
The same person needs a different home over time
The central idea eventually became very simple. Emily’s home now works around four stages. Nobody selects one. There is no badge declaring that you have reached Level Three Assistant User. The stage is inferred from what you have actually done in the product.
The first is Getting started, shown on the page as Meet Emily. At this point, the job is not to demonstrate everything Emily can do. It is to get someone through the first useful interaction. The steps are deliberately small: say hello, hand Emily a real task and set the correct timezone. That is enough.
There is a temptation in software to front load setup because it feels efficient. Ask for every preference, connect every integration, configure every setting and then let the person begin. We wanted the opposite. Using Emily should explain Emily better than a setup form ever could.
Once somebody has got through the basics, the home moves into Make it yours, shown as Teach Emily about you. This is where the relationship starts becoming more personal. Emily encourages the user to tell her something useful, save an important contact, connect a calendar and store a file they might send regularly.
Those actions are technically configuration, but that is not how we wanted to describe them. You are not configuring a memory store. You are telling your assistant something once so that you do not have to keep repeating it. You are not creating a structured contact record. You are telling Emily who someone is.
That distinction sounds cosmetic. We do not think it is. Products are often much easier to understand when they are described in terms of what the person is trying to achieve rather than how the underlying system happens to represent it.
The third stage is Become a pro, shown as Hand over the routine. By this point, Emily assumes the user understands the basics. The home starts introducing the things that make an assistant more valuable over time: rules, morning briefings and meeting arrangement.
This is where the product begins moving from reactive to proactive. The useful question is no longer simply, “What can Emily do when I ask?” It becomes, “What should I stop having to ask for?” That might be a regular briefing. It might be a rule for dealing with a certain type of email. It might be letting Emily take over some of the back and forth involved in arranging a meeting.
The final stage is Power user, shown as Emily everywhere. At this point, the dashboard is not trying to explain the concept of the product anymore. It is helping someone make Emily easier to reach. That means texting Emily from a phone, using her from ChatGPT or Claude, building the habit of handing over more work and, for eligible users, choosing a more memorable Emily address.
Organisation users do not see that last step because their address comes from the organisation. The important thing is that these are not four separate onboarding flows. They are one journey that gradually changes its assumptions about the person using it.
Fourteen steps, none of them ticked by hand
There are fourteen steps across the journey. We made one decision early that ended up shaping quite a lot of the implementation: users do not manually tick any of them.
If the dashboard says a calendar is connected, a calendar is connected.
If it says a contact has been saved, there is a saved contact.
If it says a rule exists, the product can see one.
If somebody has already completed something from a later stage, that step is already done by the time they reach it.
The current stage is simply the first one that still contains unfinished work. This means the journey can cope with people using the product in the wrong order, which is another way of saying it can cope with people using the product normally. Someone might connect a calendar almost immediately but never store a file. Another person might start using Emily in ChatGPT before they have created a single automation. Somebody else might ignore the whole journey for a week, email Emily directly and return to the dashboard having completed half of it accidentally.
We wanted all of those behaviours to work. Onboarding should reflect what somebody has actually learned and done, rather than forcing them through the sequence we happened to draw on a whiteboard. There is another benefit too. A progress indicator becomes more meaningful when it reflects product behaviour rather than the ability to dismiss onboarding cards.
And then the onboarding gets smaller
A lot of onboarding systems are very good at arriving. They are less good at leaving. The checklist that was helpful in week one can still be occupying a large section of the interface three months later. Perhaps it has been collapsed. Perhaps it is still cheerfully telling you that you are 83 percent finished.
We did not want that. While someone still has useful next steps, the dashboard shows a Next up section with the most relevant unfinished actions. Each one includes a Try it button that takes the user into the actual experience rather than another explanatory page.
Once every step has been completed, that row disappears. The journey does not vanish completely. A small progress ring remains available for anyone who wants to look back at it, but it no longer competes with the things a regular user is actually there to see.
On desktop, that ring opens the journey when clicked. On mobile, it becomes even quieter. This became one of the design principles we liked most from the redesign: guidance should shrink as fluency grows. The best onboarding experience may eventually be no onboarding at all.
The first thing you see is still Emily
Once we had the journey logic, there was a risk of making the home too focused on setup. That would have missed the point. The first useful thing on the page is still Emily herself. At the top of the home is a greeting based on the user’s own local time, followed by a simple question: What can Emily take off your plate? Underneath is an ask box. Type something there and it starts a chat. We also added idea chips around it, but rather than showing everybody the same examples forever, the suggestions change according to the stage.
A new user might see ideas that help them understand the basic interaction. Someone further along might see suggestions involving rules, research or other parts of the product they have not used yet. There are eight possible ideas per stage and the page chooses a fresh selection on each visit. A refresh button lets someone cycle through more without leaving the page.
This seems like a very small feature. We spent a surprising amount of time on it. Example prompts are powerful because they teach people what a product considers normal. If every suggestion says “write this” or “summarise that”, users quite reasonably learn that the assistant is mostly a writing tool. Emily can do much more than that, so the examples needed to reflect the breadth of the product without becoming a catalogue.
We also gave the idea chips a fairly important safety rule. Clicking one only fills the ask box. It does not send anything. The same is true of other suggestion links around the home. They can prepare an instruction, but the person still decides whether to press Send. That gives us the convenience of one click examples without creating the slightly unsettling experience of software suddenly doing something because you were trying to see what a button meant.
Making email visible again
There was another slightly paradoxical problem. As Emily gained more channels, it became easier for the dashboard to underplay the original one. Email is still one of the most natural ways to use Emily. So underneath the ask box we now show the person’s Emily address with one plain instruction explaining what it is for: email her anything, or forward an email with an instruction.
That line replaced a more prominent Copy address button during the design process. The button was technically convenient. It was also answering the wrong question. A new user does not primarily need to know how to copy the address. They need to know what they can do with it. The address can still be copied. But the explanation gets the valuable space.
Alongside it sit a few quick actions. Email. Text, where a mobile number has been configured. And Save contact, which downloads a contact card so Emily can live in the phone alongside everyone else someone regularly messages. Again, none of these is especially complicated. Together they make the product feel less like a destination and more like something that can be reached from wherever work happens.
Showing what Emily knows
One of the larger additions to the home is a section called What Emily knows. It shows counts for notes, contacts, files, rules and automations. This came from a slightly different design problem.
Memory is useful when it is invisible during the task. If Emily remembers something about a person and quietly uses it at the right moment, that is the whole point. But completely invisible memory creates its own problem. People need some sense of what the assistant actually knows.
If someone teaches Emily a preference, saves an important contact or adds a file, we want that growing body of context to feel tangible rather than disappearing into a black box. The counts are not meant to become a score. More memory is not automatically better. They are simply a compact way of making the relationship visible.
We also tightened the definitions while building it. For example, the automations number only includes automations that are actually running. A historical or inactive automation does not really belong in a number that is trying to tell someone what Emily is currently doing for them. This was one of several places where the redesign forced us to ask what a number actually means rather than simply what the database can count.
Activity should look active
The middle of the dashboard now pairs a Last 30 days activity chart with Recent activity. The original version of the chart left more empty space than we liked. It technically displayed the data correctly, but the panel looked unfinished. We changed it so the chart properly fills the space available to it. This is not an earth shattering piece of product design. It made the page noticeably better.
The large decisions were important: user stages, progressive guidance, a clearer hero, making memory visible. The quality of the finished page came from the smaller decisions around them.
Spacing.
What gets one line and what gets a card.
Whether something belongs above or below the fold.
How much a chart should breathe.
Whether a button is actually more helpful than a sentence.
Product design is often discussed through frameworks and major flows. In practice, a large part of it is looking at something that technically works and asking why it still feels slightly wrong.
Discovering Emily without reading a manual
Further down the page is Discover. There are eighteen ideas across Email, Meetings, Automations, Research and Personal. We were careful not to turn this into a wall of feature cards. Six are shown initially. If someone wants more, they can expand the rest.
Each idea explains whether it is something you would normally do by chatting with Emily or by forwarding her an email. And because different plans have different capabilities, the list only shows ideas that are actually available to that person. This is another place where personalisation does not need to mean an elaborate recommendation model. Sometimes personal simply means do not show me things I cannot use.
The section also solves a problem that becomes more important as assistants become capable of more things. Nobody is going to remember the full capability list. We do not particularly want them to. A conventional application often teaches its feature set through navigation. If there is a tab called Reports, people can reasonably assume reports exist.
A conversational assistant is much less explicit. The interface may just be a box asking what you want. That flexibility is powerful, but it can also hide possibility. Discover gives the home somewhere to occasionally answer the question: What else could I hand over?
Reach Emily your way
The next section reflects one of the biggest changes we have made to Emily recently. Email is no longer the only door. The home now brings the available channels together in one place: email, text, web chat, ChatGPT and Claude. This section exists partly as navigation, but mostly as reassurance that all of these routes lead to the same assistant.
We have written previously about the work behind making Emily multi-channel. The important product idea is that the channel should be an entry point, not a separate version of Emily.
If you teach her something through email, it should not disappear when you ask from ChatGPT.
If you create a rule in the dashboard, you should not need to recreate it before texting her.
A multi-channel assistant is only really useful if the context belongs to the assistant rather than whichever interface happens to be open. Putting those channels together on the home makes that model more obvious. And then, beneath all of this, we keep the ordinary shortcuts to the rest of the dashboard. Sometimes somebody does know exactly where they want to go. There is no need to make them rediscover the product journey every time.
We designed the journey before we released the journey
The implementation process was probably as useful as the final design. We did not make the changes directly in production. The redesigned dashboard lived first on a separate preview environment where we could treat it as a product rather than a sequence of isolated components. That mattered because the whole premise depended on seeing the same page through very different user states.
So we built something specifically for ourselves. In the top right of the preview site was a small stage switcher. Click it and the entire dashboard could immediately behave as though you were at any of the four stages, with representative sample data for each.
A brand new user.
Someone teaching Emily about themselves.
A more experienced user beginning to automate work.
A power user who had already done almost everything.
It meant we could move between day one and day ninety in seconds. That made a huge difference. Without it, judging the full experience would have required constantly changing accounts, editing test data or manually completing enough actions to reach another state. Instead, we could change one control and ask a much more useful question: Does this page still make sense for this person?
The switcher was never intended for users. So we treated that as an engineering requirement rather than a comment in the code. It only appears on the preview environment, does nothing elsewhere and automated checks make sure it cannot accidentally become part of the production experience.
There is a broader lesson in that which we have found useful elsewhere. If an internal tool must never reach customers, do not rely entirely on remembering to remove it. Make the boundary testable.
The small feedback loops mattered more than the big reveal
Once the whole dashboard could be viewed across the different stages, we could iterate very quickly. A lot of changes happened on the same day. The journey control became a smaller badge because the first version competed too heavily with the page.
The address section lost its large copy button in favour of the clearer explanatory line.
The activity chart was changed to properly fill its panel.
The page moved to the same full width treatment as the rest of the dashboard.
The automation count was tightened to reflect running automations rather than everything that had ever existed.
None of those required going back to first principles. We could see the issue, change it, take another look on desktop and phone, and move on. That pace is one of the reasons we like having realistic preview environments. Design files are useful. Component previews are useful. There is still no substitute for opening the thing that behaves like the product and noticing that one section suddenly feels enormous.
Mobile was not the final pass
We also made a deliberate effort not to treat the phone version as whatever happened after the desktop layout became narrow enough. Emily is increasingly useful away from a desk. Text is now a major channel. People check activity between meetings. A quick instruction from a phone is exactly the kind of interaction the product should be good at. So a surprising amount of the refinement was mobile specific.
The journey badge collapses down to the progress ring so it does not crowd the header.
Organisation shortcuts move into the header rather than making the side menu longer.
The ask box and Send button line up properly.
The interface avoids the sideways wobble that appears when one element is a few pixels too wide.
We adjusted the input behaviour so tapping into the text box on an iPhone does not trigger the browser’s automatic zoom.
There is also a one tap Install Emily action in the mobile menu.
None of these will ever become the headline of a product launch. They have an outsized effect on whether the product feels finished. That has been a recurring lesson for us this year. The gap between a functioning interface and a pleasant one is often made up of dozens of things that are individually too small to put on a roadmap.
The chat needed to evolve with the home
Once we had improved the ask experience on the dashboard, some of the surrounding chat interface started to feel older by comparison. So it received the same treatment.
Chat now has fresh suggestion ideas with its own refresh control.
Actions use cleaner pill shaped controls.
The confirmation for clearing chat history was simplified so the important decision is not surrounded by unrelated interface.
We also added a per-conversation choice for whether someone wants an email recap of that chat.
This was not originally the focus of the dashboard project. It happened because redesigning one important surface changes your standards for the surfaces around it. You notice things you previously tolerated. That can be inconvenient for the scope of a project. It is usually good for the product.
The release had an escape hatch
We were confident in the new home by the time it was ready to ship. We still did not assume confidence was the same as certainty. The release went behind a single switch. The old home remained available in reserve, meaning that if something unexpected happened after launch, rolling back did not require another deployment or a frantic reconstruction of the previous version.
A lot of deployment work is ultimately about making sure an interesting product change produces an uninteresting operational event. The new dashboard went live The same week, eligible users received an email introducing the redesign, with a preview of the new home and a link to try it.
That communication mattered too. It is easy to assume people will notice a redesigned interface and intuit exactly why it changed. Sometimes they will. Sometimes it is kinder to tell them.
Personal beats complete
The most obvious lesson from the work is also the one we think applies furthest beyond Emily. It is tempting to make a product home comprehensive.
Show every capability.
Surface every setting.
Give every section its own card.
Make sure nobody can possibly accuse the interface of hiding anything.
The result is often a page that technically contains everything and helps with very little. The new Emily home deliberately leaves things out.
A new user gets the next useful steps rather than the full capability map.
Discover initially shows six ideas rather than eighteen.
The journey shrinks once somebody no longer needs it.
Channels only appear where they make sense.
Plan specific capabilities are respected.
The home becomes more useful by being selective.
We have started thinking of that as personal beats complete. Not personalised in the sense of predicting someone’s entire life from behavioural data. Personal in the much simpler sense of recognising that this person has already connected their calendar, has never created a rule and probably does not need to be shown the same instructions as someone who signed up three minutes ago. There is a lot of value in simply paying attention to what the product already knows.
Teach by doing
The other principle that survived the redesign is that explanations should lead quickly into the real product.
Every journey step has a Try it action.
Suggestions fill the actual ask box.
Connecting a calendar connects the actual calendar.
Saving a contact creates something Emily can genuinely use later.
We did not want a parallel onboarding world where people complete educational tasks and then eventually graduate into the real interface. The education happens through the work.
This is particularly important for AI products because capabilities can be difficult to communicate abstractly. You can write a paragraph explaining that Emily understands natural language instructions, can use context and can coordinate tasks across connected tools. Or you can ask someone to give her one real thing to do. The second usually teaches more.
Do not let convenience quietly become action
One of the smallest decisions on the page reflects a much larger principle from Emily.
Suggestion chips never send.
They fill the input.
The user sends.
That is consistent with how we have approached the connected assistant work too. ChatGPT or Claude can help prepare an action, but consequential things still have clear permission boundaries and confirmation.
Convenience should reduce unnecessary work. It should not make it unclear when something actually happened. This is especially important as interfaces become more predictive. It would be easy to imagine a dashboard that tries to be clever enough to act before the person has really decided what they want. We are much more interested in reducing friction around intention than removing intention itself.
A good dashboard should eventually become less important
There is a slightly strange outcome to this project. We spent a fair amount of time rebuilding the page people see when they open Emily. Part of the goal is that regular users should eventually need it less. If Emily is working well, you might email her directly. You might text something while walking between meetings. An automation may already be running. You might ask from ChatGPT or Claude.
The dashboard should remain useful for seeing activity, managing context, discovering something new and changing how Emily works. It should not need to become another inbox someone feels obliged to check. That is why the new home tries to change with the relationship. Early on, it teaches. A little later, it suggests.
Once somebody knows what they are doing, much of that guidance becomes smaller and the page concentrates on what is happening now. We think that is a healthier model for software generally. Users are not static. The interface probably should not pretend they are.
A final thought
A lot of product design begins with the question: What should be on this page? Rebuilding Emily’s home pushed us towards a slightly different one: What does this person need from this page right now? The difference is subtle, but it changed almost every decision.
A first time user needs confidence that there is an obvious place to start. Someone who has used Emily a few times needs help discovering why teaching the assistant about their world is useful. A regular user may be ready to hand over recurring work. A power user mostly wants fast access, useful context and fewer explanations.
They can all arrive at the same URL. They do not need to arrive at exactly the same experience. That is probably the biggest thing we took from the redesign. A dashboard does not have to be a permanent map of the product. It can be part of the relationship with it. It can teach when teaching is useful, suggest when there is something worth discovering and quietly step aside once somebody no longer needs the help.
Which is exactly what we hope Emily does too.