Work I've led, and what it taught me.

A Fortune 50 medtech company consolidating a fragmented regional landscape onto Microsoft Dynamics, replacing everything from a deprecated legacy CRM to spreadsheets and email.

• Our side: blueprinting, Dynamics expertise, data architecture, content
• Third-party SI: the build
• Client: directing through multiple technical product owners
• Five workstreams: Sales, Marketing, Field Service, Customer Service, Regulatory Education
• Across the platform: mobile sales application, inline AI assistants

I joined as UX lead on the consulting side just as the project moved from blueprinting into execution. The client's UX team had carried upstream research but was understaffed for execution at this scale. I came in to build and lead that delivery team.

The client, platform configuration, and design system itself are covered by NDA. My role ended before the engagement closed; what follows covers the work through that point and focuses on leadership, decisions, and outcomes.

The execution phase needed UX delivery the upstream team wasn't sized to provide. Several calls were mine:

• Where UX would play across the workstreams
• What cadence design work would run on inside an SI-led build
• How design decisions would survive handoff into sprint refinement

Dynamics is a rigid SaaS surface, so the work that mattered most was experience and workflow rather than visual craft.

Built the team and the cadence.
Scaled at one to two designers per workstream depending on need, coordinated with an offshore director on staffing and workloads, kept continuity through the contract shifts that reshaped the engagement. Personally led two workstreams and oversaw capable designers on the others.

Held the seam between three parties.
The people defining the experience and the people building it sat on opposite sides of a contractual seam. My team defined how UX stories landed in JIRA and how they were spec'd for sprint-by-sprint refinement. We pushed back on the SI on AI assistant placement, on UX debt per sprint, and on design system adoption. Several escalations needed the TPOs and the client's UX director pulled in to align dev teams.

Prioritized Sales first.
Sales was the workstream the client would judge our work by. It had to come first, and it had to be convincing. The others got attention as their dependencies and TPO timelines required.

Placed AI where it earned its place.
Where AI added clarity, it stayed. Where it added a layer between the user and a task they already understood, we cut it. Decided through rough personas, workshop feedback, and close attention to where users were actually slowed by retrieval or decision support.

Built the design system that became the rollout's backbone.
Atomic tokens up through reusable templates and page-level designs, with templates defined so reusable designs doubled as reusable code components.

Editorial graphic titled "What the design system meant, depending on where you sat," comparing what the design system delivered for three groups.

• Designers got flow and UI conventions within the constraints of SaaS: documented patterns, a design system and brand guide, and consistency across teams. The result was less reinventing.
• Developers got reusable, standardized components, what design built and dev shipped: Figma mapped to Dynamics, sharing across workstreams, and less work in sprint refinement. The result was less rebuilding.
• TPOs and the SI got a shared reference and single source of truth: a central artifact to point to, grounded scope conversations, and faster alignment. The result was less debating.

Consistency where it helped. Flexibility where it didn't.

The design system held the rollout together.
Dev rework dropped meaningfully once it was in place; SI velocity improved on subsequent sprints. Patterns mapped directly between Figma and code: less translation work, fewer interpretation calls during refinement.

The Sales prototype landed harder than anyone expected.
Showcased during the client's global sales meeting with a polished commercial-style introduction. That was the point where the client's confidence in the UX direction really took hold.

The engagement doubled from its original six-month scope.
I helped shape the staffing and scope for the extension through my director. The client choosing to keep investing is the outcome I'd point to first.

Two designers came out positioned for promotion.
The associate designer who led Sales was given independent workstream leadership. One offshore designer hit a difficult stretch with delivery cadence and stakeholder communication; with coaching and some hard conversations, they came out with a noticeably stronger, more authoritative voice.

Two designers came out of this engagement ready for more than they came in with. I coached them through it; they did the harder part.

Lock the design system structure earlier.
It crystallized later than it should have. The first half of the work was spent solving similar problems in parallel across workstreams. Running this again, I'd lock the atomic patterns and template rules as a first priority, even if the full library took longer to fill in.

Distribute the pushback work.
Most of the hard conversations with the SI came through me. The cost was that I didn't build pushback capacity in the team as deliberately as I could have. The team would have grown faster if I'd been more deliberate about creating those moments earlier and more often.

An independent non-profit running pretrial services for a major US city, working alongside the police department, the courts, and corrections.

• The agency's role: to inform the release decisions the court itself makes
• Four programs: bail expediting, court-date reminders, supervised release, and the pretrial interview and release recommendation function
• The systems: a 1970s-era database behind green-screen terminals, paper files, and decades of established process
• The team: three to four researchers and analysts; I led UX
• The output: a roadmap, current and future-state journey maps, epics, and user stories

I led the UX work on a short, focused project. A new executive director had recently set out to strengthen the agency's core systems, some built decades earlier, with a database migration targeted a few years out. The work sat inside a broader push to modernize the city's pretrial services, coordinated by its criminal justice office. That push included a cross-agency data platform and a new release recommendation algorithm. (I led a separate, smaller engagement on the wireframes for that data platform in the same window.)

This was not a problem we could solve from a description of the system. It lived in places most people never see, and the staff who understood it best had never been asked to design its replacement. The calls that were mine:

• How to research work spread across a dozen locations and four programs
• How to synthesize four programs that looked different on the surface but ran into the same underlying constraints
• How to turn what we learned into documentation the agency could put out to bid, for a vendor who would build against it without ever being in the room

Put the research where the work happened.
We followed a case the way it actually moves through the city: the city's holding and booking facilities, the rooms where staff interview each arrested person within hours and often in the middle of the night, the courtrooms and the back offices behind them, and their own offices, including the one where the volume the system handled was visible in the paper it ran on.

Editorial diagram under the eyebrow "Field research: the full path," headlined "Where the research went, from the holding cell to the support that follows."

The path moves through five settings, each tied to a program and a research method: holding cells (bail expediting, observed one-on-one interviews); courthouse offices (release recommendations, watching the paper process); courtrooms (court decides, observed hearings); agency offices (court-date reminders, team interviews); and supervised release offices (supervised release, case worker interviews).

You don't get an honest picture of a fifty-year-old system from a conference room.

Interviewed and observed across every level.
Leadership, supervisors, interviewers. Decades of quiet workarounds had grown up around the system to make it serve work it could not quite do. Surfacing those was most of the research.

Mapped current and future state across the four programs.
Mapping current state meant studying the systems the way staff actually used them. The core ran on an aging keyboard-driven tracking system, with a few programs on newer or separate setups. The current-state maps were finished deliverables, faithful to how the work actually ran. The future-state maps were lighter by design, made to scaffold the workshops.

Ran the future-state workshops.
Senior staff from across the programs worked the future state themselves, building on the pain points the research had surfaced: the repetitive data entry, the communication that changed hands too many times, the work that paper and green screens made slower than it needed to be. The output was a prioritized set of epics and user stories.

The documentation became the basis of the agency's request for proposals.
In its own published account, the agency described documenting current workflows and system requirements, work that fed directly into the RFP it issued for development services. The roadmap, journey maps, epics, and user stories put the agency in a position to decide what it needed from a vendor before going out to bid.

Editorial diagram under the eyebrow "The outcome: research to RFP," headlined "The work set the terms, before a vendor could."

Four research deliverables on the left (current state maps, future state maps, a roadmap, and epics and user stories) gather into a single document labeled "the agency's RFP," which in turn points to a vendor build drawn as a dashed, not-yet outline. A footnote reads "From the agency's published account."

The workshops gave staff a stake in what came next.
The people who knew the work best had shaped the future state in their own terms. That improved the documentation, and it gave the staff a stake in the outcome.

Someone was listening to how the work actually got done.

The work outlasted the engagement.
We were on site for three months. The documentation we left behind guided decisions made long after, by the team that built what came next, in the language and priority order of the people who actually do the work.

The future-state journey maps could have done more work downstream.
The current-state maps were finished deliverables. The future-state maps were deliberately abbreviated, scaffolding for the workshops where program staff mapped the future themselves. That was the right call for the workshops. The cost was that no fully illustrated future-state map existed for the vendor that eventually built against the RFP. Running this again, I'd build the future-state maps out after the workshops with what participants produced baked in. The workshops would do the same work. The maps would carry it forward to the people building the system without us there.

HUD's Federal Housing Administration runs quality-assurance reviews on the single-family mortgages it insures. By the mid-2010s the way it ran them had not kept pace with the volume.

The hard policy work was already done. In 2015 FHA published a new defect standard that replaced ninety-nine legacy codes with nine plain-language categories, each carrying a source, a cause, and a severity tier. The standard existed. The system to run reviews against it did not. That system became the Loan Review System, and the UX work on it ran from 2016 into 2017, inside a larger federal modernization program.

• The client: the Federal Housing Administration.
• The standard: the defect taxonomy, set by FHA before the design work began.
• The users: FHA reviewers across the agency's regional centers, and FHA-approved lenders nationwide.
• My role: UX architecture and design, alongside the UX lead, who owned vision and the client relationship. We worked the hard problems together.

The old way moved on paper. Behind it sat a mainframe and an Excel workbook grown well past what a spreadsheet should hold. Reviews ran out of two divisions in each regional center, on separate systems, with no shared record.

The real problem was deeper than paper. A single system now had to serve two populations who wanted opposite things from it. A reviewer works like an investigator, weighing whether a loan met FHA's requirements. A lender wants the short version: a clear path to resolve a finding and move the loan along. Both had to be true on the same screens, in the same language.

The reviewer is building a case. The lender wants the loan out the door. The same screen had to work for both.

Built the experience on the defect standard.
The taxonomy was the one thing both sides already shared, so it became the spine: every finding and response keyed back to it. I mapped the review lifecycle end to end and designed the screens for each state, from a selected loan through findings, response, and resolution.

Organized the dashboard around whose move it is.
A lender's home screen splits in two: the reviews waiting on the lender, with due dates, and the reviews sitting with FHA, read-only until they come back. At a glance, a lender sees what they can act on and what they are waiting for. Filters by selection reason and review level sort the rest.

Editorial diagram under the eyebrow "The dashboard: whose move it is," headlined "One screen, two states, sorted by whose move it is."

The lender's home screen splits into two columns. On the left, "On the lender" (act now) holds a small set of active items the lender can act on. On the right, "With FHA" (read-only) holds a larger grid of items sitting with FHA, inactive until they come back. A footnote reads: "Read-only on the FHA side was a deliberate call. A lender always saw a review's status, and was never handed a control they could not use."

Kept the response flow legible as the stakes rose.
Resolving a finding is rarely one step. It escalates from an initial response through mitigation to formal remedies. I designed that path so a lender always knew where they stood and what was at risk at each level.

Tested it before code.
We designed and prototyped every screen before development began, so people could click through the system and react to it. The LRS team was our first audience, and the dashboard is the clearest example of what that gave us: my first cut at what a lender most needs to see was a reasonable guess, and their corrections made it the right answer.

We knew the craft. They knew the work. The design got sharper where we came together.

It pulled a scattered process into one place.
The launch folded several separate tracking systems into a single application and moved lender self-reporting off the old early-warning system. One workflow where there had been a patchwork.

Editorial diagram under the eyebrow "The standard: one way, every center," headlined "Four ways of working, then one."

A before-and-after grid. The top row, "Before," shows four panels of scattered, irregularly placed items, each a little more crowded than the last. Arrows point down to the bottom row, "After," where each panel holds the same four items lined up in a single uniform row. A footnote reads: "Ninety-nine procedures, resolved to nine, run the same in every regional center."

Both sides gained something they had not had.
FHA got reviews that ran the same way across its regional centers, against a single standard. Lenders got a clear view of every finding and a structured way to respond.

The system shipped, and it stuck.
LRS went live in 2017 and became the platform of record for the majority of FHA's Title II single-family quality-assurance reviews. The architecture held, and work continued on it for years after we finished, under the same technical lead.

I would have put the design in front of its real users.
Direct testing with them was not in the contract or the schedule, so we designed with the LRS team instead, experts who had run these reviews for years. The work was better for it. You design with the room you have.

But people who know a process stand in for the people who live it, and user testing is the first thing cut from a budget and a timeline, seldom the cheapest thing to skip. The quirks it would have caught got worked out later on the dev side, over the years that followed.