OrchidB: customer management for a B2B back office platform

01. Context

OrchidB is a back office platform helping freelancers and small businesses manage invoicing, project tracking, and customer relationships in one place, replacing the tangle of disconnected tools most small operators end up cobbling together.

The client brought us in to design a customer management page: a single place for users to view, edit, and manage their customer relationships within the platform. My role was to lead a team of five designers through the full process, from discovery through developer handoff.

02. The brief

The client gave us six user stories to design against: viewing a customer list, viewing and editing an individual customer, adding a new customer, deleting a customer, and inviting a customer to a project. Straightforward on paper, but the real brief was making those six actions feel native to a product with an already established visual identity, solid, elegant, premium, rather than bolting on a generic CRM screen.

Before designing anything, I had the team research how competitors handled similar customer management experiences, specifically Monday.com's highly visual, customizable dashboard approach, and Smartsheet's strength in cross-tool data integration, to understand what “good” looked like in this space before committing to a direction.

03. The design decisions

Decision 1: Three directions, one clear rationale

Direction A, consistent

Direction B, formal

Direction C, customizable

Explored: rather than converging early, I had each teammate design their own version of the customer screen independently, then facilitated sessions to compare approaches and pull the strongest ideas forward.

Shipped: three distinct directions presented to the client. My version, built to stay visually consistent with OrchidB's existing screens, a more formal variant with darker headers, and a more modern option with a color customization feature.

Giving the client three genuinely different options, rather than one polished direction, meant the choice they made was actually informed by trade-offs they could see, not just a single idea sold well. I pushed my team to explore divergent directions specifically so the client's feedback would be about real alternatives, not minor preferences.

Decision 2: A component library before final screens

Before: each teammate's early wireframes used slightly different patterns for buttons, menus, and layout, workable individually, inconsistent together.

After: a shared style guide and component library, built before finalizing the hi-fi screens, so every designer's work drew from the same visual and interaction vocabulary.

Building the component library mid-process, rather than after screens were finalized, meant consistency was designed in rather than cleaned up after the fact. This mattered specifically because five people were designing in parallel. Without a shared system, reconciling five sets of stylistic choices at the end would have cost more time than building the system upfront.

05. The outcome

This was a contract engagement, and I don't have access to post-launch usage data or adoption metrics. This reflects what was true at handoff, not what happened after.

What I can speak to concretely: the client approved the final direction and moved forward into development with a complete design system and developer handoff package, including sizing, padding, and technical annotations built specifically for their dev team's needs. Leading five designers through a compressed four week timeline, from independent exploration to one coherent, client-approved system, is the process story this case study is actually telling.