Why mapping every workflow is the wrong first step for a homepage meant to grow, the handoff question I’d ask about every item on it, and how the team is testing on a few workflows first.
One of our designers told me this week that getting our new homepage right would mean semi-replicating the entire product. They’ve been planning what the first screen of our product could become over the next 2 to 3 years: a place that shows a clinician what needs their attention and, over time, takes on more of the work for them. To plan for that, they figured they’d have to map every workflow the homepage might ever touch, and that list is close to everything we’ve ever built.
I’d be careful framing it that way, and I told them so in the review. What I’d love to see is a framework: some logic that decides, for anything that earns a spot on the homepage, how a person interacts with it there. Set those standards for a few things up front, test them, and then expand them one by one. What evolves over time is the framework and its principles, which means the UI needs to be built flexible enough to take whatever the team learns.
The next day, in our 1:1, I said it more simply. One day you will boil the ocean. But we need to get testing, using existing simple use cases and flows, to test out the system that will scale to support boiling the ocean, and that system is what you’re focused on in the near term.
One day you will boil the ocean. But we need to get testing, using existing simple use cases and flows, to test out the system that will scale to support it.
The question I’d ask about every item is what happens after someone taps it. In the review, the example was a denied insurance claim sitting in the list of things that need attention. If you hit resubmit, does the homepage update to tell you it’s handled, or does it drop you into the billing side of the product to find your own way? There’s an opportunity in that moment for a nice handoff versus just a drop into something: we got this, we’re resubmitting it on your behalf, and you can check the latest status here whenever you want. A team that gets that right for a few items has a pattern it can map onto every other feature, one at a time.
A product leader in the session (I love that PMs come to our design crits, by the way) gave the team a useful way to sort those items. Some get resolved in a click or two right on the homepage, some open a side panel, and some send you to the full workspace where that job lives. An engineering leader described the relationship between the homepage and those workspaces as a contract: the homepage surfaces the work and hands it to the place that owns it, so it never has to know how to file a claim itself. (I wrote about deciding what a home screen is for in Issue 25, and this is the work that comes after that decision.)
The counterweight arrived in crit later in the week, and it was a good one. One designer described the homepage as a launchpad, and another answered that they agreed, but if there’s nothing to launch to… Some of what clinicians want surfaced has no workflow anywhere in the product yet, so putting it on the homepage means you see the problem there and lose sight of it the moment you leave. The team leaned toward showing those items as view-only for now. The better question, they said, is what the homepage can do today, with high confidence, that won’t make people relearn the workflow once the owning team builds it.
A detail from the team’s research made the case for starting small. Today most clinicians find out what needs their attention by happenstance: a weekly report, a stray notification, landing on the right page by chance. A homepage that handles 3 things well is already a big step up from that.
So the plan is a pilot of 3 to 5 jobs, scored on what triggers each one, how it gets resolved, how often it comes up and how painful it is today. When an early presentation made it sound like every team had to hook in at once, I gave that feedback after crit: the pressure we’re under is to get something tested, with very small segments and a very small scope, and calling it getting something out implies a launch to everyone. If the team does that well with 3 workflows, it will reinform how they evolve the framework. The framework will get more complex over time, and it will still be good, because they’ll be working in smaller pockets, closely with the teams that own each feature.