The work behind the work.
Six months of provider research and service design. A feature proposal for an internal tool that never shipped because the platform closed first.
A feature recommendation that came out of service design.
This was not a shipped AI product. It was a six-month service design project that turned into a structured proposal for an internal tools team.
Therapists (Providers) on a Dynamics 365 internal platform were struggling. The platform had real technical issues, failures were costly to the business, and the complaints and user-drops were piling up. After interviewing six Providers and mapping their experience end-to-end, I proposed an AI assistance layer to remove a category of clinical busywork, and worked with the TELUS AI engineering team to keep the proposal grounded in what was actually feasible.
The proposal was presented to the D365 internal-tools team. It never shipped. Before implementation, TELUS made a strategic decision to move Providers to a separate program and retire this part of the platform.
The work that follows is what survived: the research, the personas, the segmentation, the service blueprint, and the trust-model proposal that drove the recommendation.
A platform that was already failing the people running it.
The Provider workflow lived inside an internal Dynamics 365 platform. It had been built for case management and evolved into a clinical surface without a clinical UX. By the time I joined the project, the operational signal was clear:
The bet I made: if there was a clear, evidence-backed proposal, one rooted in actual Provider interviews, with a feasible AI scope and a documented trust model, the internal-tools team would have something concrete to consider. That bet was the project.
Interview six Providers. Build the persona and the blueprint. Then propose anything.
Service design first. The AI feature was the last thing on the page, not the first.
Five pieces from the six months.
The interview research, the Provider segmentation, the trust-model proposal, the end-to-end user flow, and the deck I used to present it to D365.
Six Providers. One workday at a time.
Interview research, raw notes, themes, and the early-blueprint scaffolding all on one canvas. The artifact let the team move from individual quotes to grouped pain points without losing the source.
This is what made the eventual feature proposal defensible. Every recommendation had a Provider behind it.
Six Provider categories. Three axes. One persona.
From the interviews I clustered Provider needs into six categories, tech adoption, ease of use, communication, payment, support needs, client care, and segmented across three axes: tech-adoption level, process-complexity tolerance, and administrative-support requirement.
The persona, empathy map, and journey map at the bottom of the board are what the proposal pointed at when it had to answer the question “who is this for?” in a meeting full of internal-tools engineers.
Five questions before the UI.
The trust model was the spine of the proposal. For each AI moment, the same five questions: what does AI propose, who approves it, how clearly are the seams shown, what is logged, what can be undone.
It was the part the AI engineering team and the internal-tools team both pointed at. Engineering used it to pressure-test feasibility. The internal-tools team used it to understand what they were being asked to build, and what guardrails came with it.
Hannah's appointment, seen end-to-end.
Six steps, three actors, two AI moments. Hannah is the member, Brad is her counsellor, AI sits inside the Provider Hub. Pre-session, in-session, then a same-day handoff back to the member.
The highlighted step is where AI earns its keep: the call transcript becomes a structured SOAP draft, and Brad edits and signs it. Every other moment is human-led. The last step (Hannah opens the app to a plan, not an empty inbox) is what made the proposal worth presenting.
Eight slides. One ask.
The proposal deck I built for the D365 internal-tools team. Eight slides, no decoration: title, agenda, the Provider persona, three research themes, the AI feature set, the trust model, what changes for members, and a phased ask that ships the SOAP note first and earns the rest.
Every slide tied back to a research theme or a trust gate. The closing slide is the only place the deck asks for anything: joint scoping with D365 and AI engineering, one sprint to v0, audit log on day one.
Brad has 10 minutes before his call with Hannah.
Brad pulls up Hannah's record. Without AI, his only path is opening every clinical note from her file and re-reading them under the clock. With AI, he gets a summary of her Episode of Care, recent assessments, and any care-plan activities she's done independently, plus a small reminder: Hannah talked about her new puppy last session.
Brad opens the session by following up on Hannah's care-plan activities and asks how the puppy is doing. Hannah notices the personal detail. It's small, but it matters: stepping into counselling is hard, and Brad sounding like part of her whole care journey makes the rest of the session land differently.
The session ends. Without AI, Brad's next 20 minutes are spent typing notes into an unstructured text field, or pushing them to later if his next call is on top of him. With AI, the call transcript is summarized into a standardized SOAP draft. Brad reviews, edits, approves, signs.
Then AI does one more thing. It takes Brad's clinical notes and queries the TELUS Health content database, surfacing resources and homework directly inside the session form. Brad picks the ones that are right for Hannah and sends them. Hannah opens the TMH app to a recap, action items, and resources Brad chose for her, not a generic article and not an empty inbox.
That's the loop. Two AI moments (the pre-session summary, the post-session SOAP+resources). Every other moment, Brad is the one doing the work, with the AI in support.
What the proposal actually contained.
What it was projected to do.
“An AI-provider assistant would significantly streamline provider workflows at TELUS Health. This system would allow providers to input session data, receive AI-generated SOAP notes, which they can review and edit before submitting to the HUB.
This approach would not only save time but also standardize clinical notes across TELUS. It would enable providers to quickly locate and share TELUS-branded resources with members in real time, enhancing efficiency and resource distribution.
By implementing this AI-assisted system, TELUS can improve consistency in documentation while allowing providers to focus more on patient care and less on administrative tasks.”
The platform closed before the feature could.
The AI feature was not implemented. The reason was strategic, not design-side: TELUS decided to move Providers to a separate program and retire this part of the platform permanently. Technical instability had been costing the business and the user base for too long. Closing the surface was the call leadership made.
That decision happened after the proposal was presented to the D365 internal-tools team and before any implementation work began.
The honest framing of impact is what survived the platform's closure:
- The Provider research, segmentation, persona, journey map, and service blueprint became reference artifacts the team could carry into the successor program. They did not need to be redone.
- The trust-model framework outlived the project. The five-question structure transferred cleanly to subsequent AI conversations across the design org.
- The proposal made the case for closing the platform clearer. The artifacts gave leadership a documented view of the experience that backed the decision to move Providers elsewhere.
- The collaboration model with the TELUS AI engineering team, design proposing, engineering pressure-testing feasibility before commitments, became a pattern I have used since.
A project doesn't have to ship to be the right project.
What I learned. Senior design work is sometimes about making a decision easier to make, not making a feature easier to build. The cleanest outcome of these six months was not a shipped product. It was a body of evidence that helped leadership decide to close the right surface and move Providers somewhere they could actually be supported.
What I'd do differently. I'd push earlier for direct co-presentation with the AI engineering team to the internal-tools group. We did the work in parallel; we should have done the room together. A unified design + engineering proposal lands differently than design alone.
The thing I keep using. The trust-model framework. Five questions, in order, before any UI: what does AI propose, who approves it, how clearly are the seams shown, what is logged, what can be undone. Every AI conversation since has fit inside that structure.
Service design isn't the prelude to the “real” design work. Sometimes it is the work, and the artifact a leadership team uses to make the right call is the thing that mattered.