Design Practice and Process Building

Establishing Design Principles, Process, and Persona Practice at Fastroi (RTC)

But the product told a more layered story than a single business relationship would suggest. Alongside the office-facing management tools used by admins and managers, RTC also shipped a mobile app used directly by care workers in the field, coordinating care for the organization's own customers — the patients. Commercially, the relationship was B2B. Functionally, the value chain ran Health care/Social care organization → care worker → service user — closer to B2B2C.

That distinction mattered because decisions were largely made on assumption, without a shared understanding of who the different users actually were. User stories came from business requirements, not user research — so nothing forced anyone to reason about the office admin, the care worker, and the patient as separate people with separate needs. Nobody had mapped that gap yet. That gap is where this case study starts.

The problem underneath the problem

My first assignment was tactical: redesign a clunky old feature (User Account Management). But almost immediately, the tactical work kept surfacing the same structural issue.

• There were no documented design principles guiding decisions.

• There was no defined design process — UI/UX design existed as a single, undocumented step inside the product management process.

• There was no persona or user research practice. Decisions about the three different user groups were made on assumption, filtered through whichever product manager or salesperson had last spoken to a client.

• Access to real users — the care workers and organizations actually using the product — was largely closed off. Clients controlled that access and weren't interested in opening it up for research.

In other words: a company operating a B2B2C model, making B2C-sensitive decisions, with a B2B-only feedback loop. Nothing forced anyone to confront that until it started showing up as inconsistent user stories, conflicting assumptions in meetings, and UI decisions that didn't hold together across the product.

Design didn't yet have the scaffolding to work from — so building it became part of the job.

What I built

Design Principles

I mapped the business and marketing goals (what they were, why, how Fastroi tried to fulfill them, what success looked like), cross-referenced them against the product's stated primary features (daily work management, care work management, work time management) and against the three target groups the B2B2C shape actually implied: office users, care workers, and the indirect end customer. That became RTC's first documented set of design principles, giving the team a shared reference point instead of case-by-case judgment calls.

Design Process

Design existed as one vague box inside the product management flow, with no visibility into design review or evaluation. Over roughly two months, I proposed and helped establish a dedicated UX/UI design process — one that placed user research at the start of any new feature (either fresh or built on prior findings), wove in UX evaluation at defined milestones so the team could course-correct, and stayed interlocked with the product and development processes rather than sitting apart from them.

A proto-persona practice, built out of a workaround

Formal user research needs access to real users, and that access wasn't available Rather than treat that as a dead end, I ran the closest available alternative: structured interviews with 8 people inside Fastroi — spanning product, sales, development, and marketing — asking about the different RTC user types, their traits and responsibilities, and their needs and frustrations. I ran the results through thematic analysis.

Two things came out of it:

• Office-based users (admins, accountants, managers) converged into a single persona whose needs are mostly shaped by their organization's own process;

• Care workers, by contrast, split into three to four distinct proto-personas, since their context — age, contract type, work setting — varied far more.

Not a substitute for real research, but a first, evidence-organized answer to "who are we actually building for" — the very question the B2B label had let the company avoid asking.

Putting it into practice

With the principles and process in place, I used them on the work already in front of me — most notably a full redesign of User Account Management, one of RTC's oldest and most tangled flows. The feature's core difficulty was that nearly every attribute (user role, service line, unit, etc.) carried its own "valid time period," each needing to reconcile against the account's own validity window — a logic tree that had never been mapped end-to-end. I traced the user stories and product logic, built basic user journeys, and took the flow from low-fidelity wireframes through to a phased, three-step account creation process — the first structured process the feature had ever had.

The same thinking carried into restructuring the Settings and Configuration information architecture, which had grown two overlapping, inconsistent sections (Administration and Settings). Where categorization wasn't obvious, I ran a hybrid card-sorting study with 7 colleagues rather than guess — a small, low-cost way of getting outside my own assumption, in an environment where getting outside anyone's assumptions was the whole problem./p>

Why it matters

None of this started as a strategic exercise — it started because a UI redesign task kept running into a company that hadn't yet asked itself who its real users were, or agreed on how design decisions should get made. The B2B framing had let a B2B2C reality go unexamined; without principles, a process, or a shared idea of the actual user, every decision was reinvented from scratch, by whoever happened to be in the room.

That's the pattern I still work on today, just at a different scale: organizations that have a customer strategy on paper — or in this case, a business model on paper — while the operational layer underneath tells a more complicated story. The fix isn't more research or more strategy decks. ow It's building the missing infrastructure — the principles, the process, the shared reference points — so that reality, once surfaced, actually has somewhere to land.