CASE STUDY 04
UX CONSULTING + STRATEGY
Embedded UX consulting at scale
Helping product teams make better UX decisions quickly across a complex healthcare platform.
As a Senior UX, Usability Specialist, I responded to Internal Requests assigned by the UX team mentor, diagnosed the underlying problem, and recommended appropriately scoped UX guidance before and during product development.
- Role
- Senior UX, Usability Specialist
- Environment
- Enterprise healthcare / Electronic Medical Record platform
- Collaborators
- Product Analysts, Product Management, Engineering, Clinical Risk Management, UX
- Cadence
- Approximately 3 to 7 IRs per week alongside larger projects
- Focus
- Appropriately scoped UX guidance before and during product development
The Challenge
Many product teams needed UX judgment at the same time
UX support was needed across teams working on different parts of a large EMR platform. Requests ranged from UX writing and design validation to workflow issues reported by customers and patient safety concerns.
Inputs could include screenshots, mockups, complaints, or existing workflow documentation. The challenge was deciding what was actually causing the problem and how much UX investigation was responsible.
What is actually causing the problem?
How much investigation does this need?
What is the smallest appropriate UX intervention?
When does a seemingly small issue indicate a larger workflow problem?
PROCESS
A fast path from request to responsible recommendation
Each Internal Request moved through a lightweight consulting process that helped me clarify the problem, investigate the workflow, and return practical UX guidance without forcing every issue into the same level of research.
ASSIGNED
An Internal Request was submitted through the company's internal platform and assigned to me by the UX team mentor.
CONSULT
I immediately scheduled a 30 minute consultation with the Product Analyst who submitted the request.
INVESTIGATE
I clarified the underlying problem, then investigated as needed by reviewing the workflow, reproducing the issue in the EMR test environment, examining customer feedback, or evaluating the proposed design.
RECOMMEND
I developed the appropriate UX response for the problem.
COLLABORATE
When feasibility became a concern, I worked with Product and Engineering to adjust the recommendation while protecting the user need.
HANDOFF
I returned the recommendation and supporting artifacts to the Product Analyst for the next product step.
Outputs followed the problem
Outputs could include written UX recommendations, UX copy, annotated screens, wireframes, low fidelity designs, Miro user flows, mini usability or research reports, and workflow recommendations.
METHODS
The right amount of UX for the problem
Not every UX problem needed a lengthy research study. Good UX judgment meant matching the method to the risk, evidence, and decision that needed to be made.
LIGHTER INTERVENTION
Focused UX guidance when the problem was narrow and the risk was contained.
- UX writing
- Notification copy
- Error messaging
- Checkbox or toggle behavior
- Design validation
- Interaction recommendations
MODERATE INVESTIGATION
More structured evaluation when the request involved workflow, behavior, or design tradeoffs.
- Workflow review
- Test environment investigation
- Wireframes
- Low fidelity mockups
- User flow analysis
- Heuristic usability evaluation
DEEPER INVESTIGATION
Escalation when an IR exposed a broader workflow or research problem.
- Larger UX project backlog
- Lead or Director review
- Deeper research recommendation
When an IR revealed a broader workflow or research problem, I recommended escalation into the larger UX project backlog for Lead or Director review.
CONSTRAINTS
Good UX had to work in the real system
The ideal UX recommendation was not always technically feasible within the available timeline. When Product or Engineering identified constraints, I worked through the tradeoff with them instead of treating feasibility as a reason to drop the user need.
Understand the constraint
I worked with Product and Engineering to understand what was not feasible within the available timeline.
Protect the user need
The goal was not to abandon the UX recommendation. It was protecting the core user need while respecting technical and timeline constraints.
Adapt the solution
I modified recommendations with the team so the final direction could work in the real product system.
Prioritization and scale
The volume required active workload judgment
I typically balanced approximately 3 to 7 IRs per week alongside larger research and design projects. According to a UX team mentor report covering work since April 2024, that work represented a broad embedded UX role across rapid consultations and larger projects.
Patient safety came first
Prioritization was dynamic. P1 patient safety requests took immediate priority, while other work was balanced against severity, Product Analyst timelines, development and release deadlines, complexity, and my larger project commitments.
While representing ~7% of the measured team, this work also represented 12% of team IRs and 15% of team projects.
The team comparison was based on approximately 14 people included in the mentor's calculation.
IMPACT
Trust showed up in how people brought me into the work
The impact was organizational rather than a measured outcome after release. The value was practical UX judgment entering product conversations while decisions were still being shaped.
Trust indicators
Requested partner
Product Analysts frequently requested to work with me specifically.
Complex IR support
I was regularly trusted with complicated Internal Requests.
Team resource
Junior UX team members came to me for help when they received difficult IRs.
Organizational impact
UX guidance entered product conversations while decisions were still being shaped.
Product teams had a repeatable path for getting practical UX guidance without turning every issue into a large research project.
Larger workflow or research problems could be identified and elevated for deeper investigation.
REFLECTION
Rigor is choosing the evidence a decision needs
This work changed how I think about research rigor. Rigor does not mean applying the same process to every problem. It means knowing what evidence is needed to make a responsible decision and recognizing when the problem requires deeper investigation.
At this pace, the important skill was not just moving quickly. It was knowing when a focused recommendation was responsible and when the issue needed more structured investigation.
Strong UX judgment means knowing how deeply to investigate before making a decision.