People Log In with a Question

When a windshield gets chipped on the highway or a door gets dinged in a parking lot, people open their insurance app with one question: “Am I covered?” The app opens on their premium and their next bill, because it’s built around billing. The answer is buried in a PDF of policy language, and too often the surest way to find out is to file a claim, which means committing to an action just to learn something. People come back to a lot of software as investigators, with a question they need answered, and I design for that question first.

As principal product designer for a wholesale ordering platform, I designed its dashboard and led the front-end build. Manufacturers sell through sales agencies, whose reps take orders from retailers and earn a commission on each one. Those reps and their agencies are the people this series follows. The platform was built around taking orders, the way the insurance app is built around the bill, and a rep’s version of “Am I covered?” was “Which of my orders are held up?” An order is held up when it sits in a status like pending, waiting on something such as a retailer’s payment. The platform had no page that listed held-up orders, so reps exported orders into a spreadsheet workbook to find them.

The project started with a complaint and a mandate. The complaint was that people working on an order couldn’t open a related record, like its retailer or the products on it, without losing the one in front of them, so they kept a browser window open for each kind of data. The mandate was to add reporting, which meant something different to every stakeholder and coworker I asked, so I asked the people using the platform why they wanted reports. Nearly every answer described the same task: noticing a problem such as a held-up order, triaging it (working out whether it matters and what to do), and fixing it. The complaint and the mandate turned out to be one problem: the platform could take and change orders, but it had nothing for noticing or triaging, and nowhere to hold on to what people found along the way.

The dashboard was the first page people saw when they signed in, and whatever it showed was the first thing they noticed, so I made it the place for noticing and triaging. Instead of the usual links to workflows like “add a new order,” it showed up-to-date numbers, like a count of held-up orders, and each number opened a table of the orders behind it on the dashboard itself. When someone needed to act, the order, its retailer, or a product opened in the platform’s own screens in a new browser tab, and the dashboard stayed where they’d left it. Two tabs now did the work of a window for each kind of data. The dashboard never edited an order: fixing one happened in the platform’s order screens, and the dashboard’s job was to get people to the evidence and leave the judgment to them.

The product team and I researched the dashboard through weekly sessions with reps, a monthly council of agency owners and reps, and surveys. It rolled out in stages until thousands of reps were using it, with some parts finished while others were still in alpha or beta. Each article stands on its own and says whether its evidence came from research sessions or from how people used the dashboard after release.