Project case study
A grounded project that adds a different angle without repeating the others.
When a long-running client asked us to look at their internal support interface, the brief was simple: make it easier for the team to spot what actually needed attention. The old dashboard worked, but it buried the useful signals under layers of generic activity feeds. This refresh was less about visual flair and more about restructuring how information flows to the people who act on it daily.
The support team handled roughly forty open threads on any given day, spread across email, a shared inbox, and a project management tool. Nothing was lost, but nothing was prioritized either. Agents spent the first hour of each shift rebuilding context from scratch: who had replied last, which client was waiting on a decision, what had already been tried.
We spent two weeks shadowing the team and mapping their actual workflow before touching any interface. The pattern that emerged was consistent: people did not need more data, they needed a clearer sense of what was stuck. The dashboard was showing everything with equal weight, so nothing stood out.
The core decision was to shift from a chronological feed to a status-driven layout. Each open thread now appears under one of three states: waiting on the client, waiting on us, or in active discussion. That single change removed most of the guesswork from the morning review.
We also introduced a lightweight escalation flag that appears only when a thread has been silent for more than three business days or when a client has asked the same question twice. The flag is subtle, a small marker next to the thread title, but it gives the team permission to prioritize without feeling like they are ignoring anyone.
The refresh reused the existing backend and focused entirely on the presentation layer. We worked with the client's internal developer to map the data model, then built a static prototype in plain HTML and CSS first. That prototype became the reference for the final implementation, which kept the same structure but connected it to live data.
Timeline was tight, about six weeks from first workshop to deployment. We ran two rounds of usability testing with actual support agents, not managers, and adjusted the information hierarchy based on their feedback. The second round took half the time because the core layout had already stabilized.
The most telling metric was not speed, though average first response time did drop by about a day. What stood out was how the team described their morning routine. Several agents mentioned that they no longer needed to open every thread to know where things stood. The status view gave them enough context to decide what deserved a closer look.
One unexpected outcome was that the escalation flag changed how the team communicated internally. Instead of asking "has anyone looked at the Acme thread?", they could point to the marker and agree on next steps in a single conversation. The dashboard became a shared reference point rather than a personal to-do list.
The client has since asked us to apply the same status-driven thinking to their project handoff process, which is a separate piece of work. For this refresh, the goal was to reduce friction in daily support work, and the feedback suggests it did.
Filed under interface work and internal tooling.
A short look at recent commissions and internal projects. Each case includes the original brief, the decisions made along the way, and the final outcome. Follow the links to read the full story behind the work.
Case Study
This page frames a concrete subject instead of using a generic heading. It explains what is being considered, why it matters in the site's context, and what detail a reader can expect next. The copy is intentionally plain and specific, so it reads like a real content item.
Read the caseProcess
This item focuses on practical use, tradeoffs, and decisions that a reader may recognize. It avoids broad promotional claims and keeps the topic tied to a clear situation. The description gives enough substance for a real page rather than a placeholder card.
Read the caseInterface
This page gives the third item its own reason to exist. It covers a separate angle, includes concrete context, and avoids repeating the same promise in different words. The result should feel like a planned article, project, review, or offer.
Read the case