App Lifecycle (deep draft) — Kaili Miyamoto
Protected
This case study is password protected

Enter the access phrase to read the full study — or request it.

That phrase isn't right — try again.
← Work App Lifecycle Mgmt Next →
Microsoft · App Lifecycle Management

One guided path from built to published.

A guided, agent-assisted workflow for publishing employee-built apps to the Microsoft catalog.

I owned the end-to-end design, built new components, rebuilt the ALM design system, and introduced AI into a manual process.

Role
Product Designer
Timeline
2025 — 2026
Type
Agent UX · Admin surfaces
Impact
0%
less time to publish an app or agent live to the M365 catalog.
90days
SLA turnaround on reviews that once took a quarter.

Fewer handoffs, fewer errors: one guided path replaced a dozen disconnected screens.

The short version

Where the time actually went.

Everyone assumed the tooling was slow. It wasn't, and that changed what I built.

Timed the pipeline

Followed submissions end to end before touching a screen.

Found the real bottleneck

The days sat in the review queue, not the tooling.

Rebuilt the design system

New components, one language across ALM.

Replaced the screens

A dozen disconnected screens became one guided path.

Moved the fix upstream

Weak descriptions get caught where they're written, not in review.

Ranked the queue

Risk read off the manifest picks the path — green shortens it, nobody skips it.

Argued down auto-approval

The agent prepares the package. A person still decides.

The problem

The product worked. It just took forever.

Managing an app's lifecycle meant hopping across a dozen disconnected screens. Three things kept biting.

01
Dated
The interface hadn't kept up with how people actually work.
02
Manual
The workflow was full of repetitive steps a machine could handle.
03
Slow
Employees waited far too long to get the apps and agents they built live on the Microsoft catalog.
How we knew

We didn't guess at the bottleneck. We timed it.

Before touching a screen, we followed submissions end to end and recorded where the days actually went. All three pointed the same direction.

Status
Almost every support thread was someone asking where their app was, not how to move it forward.
Repetition
Reviewers ran the same checks by hand on every submission, most of which passed. The judgment calls were the minority.
Review
The days went here, not to the tooling. Submissions sat in one queue and every one got the same scrutiny, whatever it was.
The decision that mattered

Most of the wait wasn't in the tooling.

A dozen screens is slow, and replacing them with one fast screen is the obvious fix. It would also have moved the wait rather than removed it, out of the tooling and into the queue, where most of it already sat.

So I stopped asking how to shorten the path and started asking how much of it a person needed to be in, which submissions belonged in it at all, and which parts they had to stay accountable for.

01

One guided path

An employee publishing an app doesn't know the sequence. They know the outcome they want. The old interface asked them to know both.

The alternative was a better dashboard: everything visible at once. I argued against it. A dashboard is faster for the handful who publish every week and close to useless for everyone else, and everyone else was most of the traffic. So the admin states the outcome and the agent lays out the sequence. Guided isn't the same as hidden: every step is on screen before it runs, and they can step out at any point.

02

A minimum bar, before the queue

A thin app description isn't a cosmetic problem. It gets flagged in review, sent back, rewritten and republished. One submission making the same trip twice. Fixing it after the fact was costing more queue time than the review it failed.

So the description is evaluated where it's written, not where it's read. A weak one comes back broken out by clarity and completeness, next to a rewrite the submitter can take, edit or ignore — and they can still submit as-is. That dialog was the one I argued hardest for, because it names the cost instead of blocking the action. Most people fix it once they know it'll cost them a second trip.

Description needs work AI analysis
Clarity28%
Completeness34%
What they wrote
App for teams. Helps with tasks and stuff. Easy to use.
Suggested rewrite
Assigns, tracks and closes recurring team tasks inside Teams. Reads the channel's existing task list, routes each item to an owner, and posts a daily digest of what's overdue. For teams of 5 to 200 who already run standups in Teams.
Use rewrite Edit it Submit as-is
The evaluation broken out, with the rewrite the submitter can take, edit or ignore.
03

The Risk-o-meter

Review was the queue, and the queue had no order to it. A form-filling utility built by one team waited behind an app requesting broad tenant permissions, and both got read with the same care.

Risk used to be whatever the submitter declared. Now the system reads it off the manifest — what the app can reach, write to and touch — and returns green, yellow or red. The color picks the review path, not the decision. It also has to be readable: if a reviewer can't see what's behind a rating, they can't argue with it, and they stop checking it. So every color opens into its signals, and a reviewer can override it either way, recorded against the assessment rather than the app. The override started as a safety valve and turned out to be the thing that kept reviewers reading.

Risk AssessmentGREENAuto-evaluated based on manifest
Permission Reach = Self
Access limited to user-uploaded HR handbook files, not org-wide or tenant-wide.
No write exposure anywhere
No connector or tool writes data to any location.
No sensitive data
Fully assistive, Level 1 (End-user)
Every assessment opens into the signals that produced it, in the reviewer's language: permission reach, write exposure, sensitive data.
Publish RequestUPDATERISK-BASED FRYELLOW
Request state
Business Review
Created date
Mar 10, 2026
SubmissionMar 9, 2026
Validation2d 7h 11m
Business Review1d 4m
Security1d 4m
Privacy1d 4m
RAI1d 4m
Three reviewers, running at the same time
Feedback
Processing
Completed
Green shortens the path; it doesn't remove anyone from it. Yellow picks up Business Review, fanning out to Security, Privacy and RAI at once.
04

AI-assisted review

Evaluation runs in parallel with the upload rather than after it, so by the time a submission reaches a reviewer the checks are done and the summary is drafted. Their first minute goes to the decision, not to the setup for it.

The decisions stay with separate reviewers, each owning their own call on the same prepared package: the agent writes the summary, and each reviewer approves, rejects or pauses within their own remit. The hardest argument on the project was whether the agent should go further and approve green submissions outright. I held that it prepares the material and a person decides, so someone who wasn't in the room can still see who decided what, and why.

Publish RequestUPDATERISK-BASED FRYELLOWProcessing time: 2d 15h 41m
Prepared by the agent
Request stateProcessing
Submitted onNov 12, 2025
Sub-typeUnified M365
Version1.0.3
CapabilitiesBot, Connector, Sharepoint
Decided by the reviewer
Select an action for this publish request:
Approve
Reject
Pause
Review comment:
The agent's draft and pre-checks, with the decision still the reviewer's.
App Lifecycle Management home, with every app and its current state Submit Your App or Agent, with the AI Analysis panel scoring a weak description The rewrite applied, with the option to re-evaluate before continuing Publish Request Details beside a green Risk Report auto-evaluated from the manifest A completed publish request with its risk read attached

Every app and agent in one place, with the state it is actually in.

The description is evaluated where it's written, next to a rewrite you can take or edit.

Rewrite applied, and re-evaluated before it moves on.

The Risk-o-meter reads the manifest and routes the submission.

Completed in two days, with every check it passed attached.

Takeaway

The fastest way to speed people up wasn't a slicker screen it was letting AI carry the steps that never needed a human.

What held

The guided path shipped as the default, and the override has stayed in use. That's the number I watch — it means reviewers are still reading.

What I'd change

Business Review runs Security, Privacy and RAI at once, but none of them can see what the others are looking at. I gave them parallel review without a shared view. That's what I'd build next.

The description evaluation and the risk read also never compare notes, so a description promising what the manifest doesn't grant only surfaces when review sends it back. Catching that at submission would save the same trip the description check already saves.

More work All projects →
{{ r.num }}
{{ r.name }}