Selected work
FactorLab · SmartTagIt / WORKFLOW DESIGN · PRODUCT COLLABORATION
Give an observation a path to action.
Extending an existing observation flow so people can raise an issue, request approval, and understand what needs to happen next.
3 min read
- The task
- Turn an observation into an issue or approval request that someone can act on.
- My contribution
- Mobile interaction design, shared forms, annotated walkthroughs, and implementation refinement.
- Where it landed
- Core workflow reported live in September. Report and email extensions remained in progress.
01 / Entry and action
Raise the issue where it is noticed.
I kept Add detail beside the response, then explored a choice of follow-up actions. The observation remains the context for the issue.
Start beside the response
The entry sits beside the answer it explains.
Inspect screen
Choose the next action
September 8 design iteration. The reduced action sheet differed from the initial implementation.
Inspect screen
Keeping the action beside the response reduces the need to remember where a problem was found. We could extend the observation flow without making every observation an issue.
Decision notes and evidence
Alternatives and constraints
- Alternatives
- Keep separate media actions or consolidate related actions in a smaller sheet.
- Constraints and tradeoffs
- The reduced sheet made a compact design direction visible, but combined media capture required its own engineering decision. I kept that proposal distinct from the initial implementation.
Evidence behind this account
The original walkthrough and later design capture show the entry and explored options. They do not establish that the exact reduced sheet shipped.
02 / Issue / approval
One structure, two responsibilities.
An issue and an approval request share a form pattern. Their statuses, required fields, and primary actions make the different responsibilities visible.
Raise an open issue
Open status; assignment is optional in this design.
Inspect screen
Request approval
Awaiting approval; a named assignee is required.
Inspect screen
Shared fields make the forms familiar. Different statuses, required inputs and actions explain who needs to act next. I used those distinctions to make the handoff easier to review with engineering.
Decision notes and evidence
The review changed the handoff
| Question | My response | What it changed |
|---|---|---|
| How should editing work? | Compared a separate read view, direct editing, and fields that become editable on tap. | Recommended direct editing for the current phase and retained the inline alternative for later. |
| Should existing comments and media disappear? | Asked product to clarify a desktop demo that omitted those options. | Product confirmed that the existing options should remain. |
| How should workflow appear in a report? | Designed examples that distinguish workflow status from an existing permit approval. | The report mockups reached an engineering ticket for review. |
A summary of design and review decisions. It is not a claim that every follow-up change was implemented.
WHERE IT LANDED
From form designs to an implementation conversation.
I delivered the mobile designs and walkthroughs, then refined editing and reporting details with engineering. The team reported the core workflow live September 23, 2026. Email and report extensions remained in review.
What I learned and would test next
A shared form can simplify design and implementation, but each task still needs clear ownership, requirements, and status.
Check whether people can find an assigned issue, distinguish a question-level issue from a session-level request, and follow its status without help.
Original September mobile design captures and dated handoff and implementation correspondence. Screens show design iterations. Release is attributed to the engineering update; no measured adoption or usability gain is claimed.
KEEP EXPLORING