The primary field action should be available immediately, without forcing staff through a task feed or project-selection flow first.
From field capture to verified completion
Designing a shared operations workflow for country clubs and sports facilities — from capturing an issue on a phone in the field to reviewing its resolution on the web.
Overview
Designing one loop, from field capture to verified completion
Walkthrough Labs is a facility-intelligence platform that helps operations teams document repairs, assets, incidents and events with visual evidence. Staff can capture what they see in the field, assign responsibility, and keep a searchable record of what happened and how it was resolved.
I redesigned the product around that complete loop — from capturing an issue on a phone to reviewing its resolution on the web. The engagement covered the mobile app, the operations dashboard, a responsive marketing site, iterative client releases and developer handoff.
Identify→Capture→Annotate→Assign→Complete→Review
40+mobile screens designed across three documented releases
3surfaces — iOS app, operations dashboard, responsive marketing site
12slide UX audit with findings grouped by workflow risk
| Role | Product Designer — UX audit, information architecture, interaction design, UI design, prototyping, specifications and handoff |
| Timeline | February 2025 – ongoing |
| Platforms | iOS mobile app, web operations dashboard, responsive marketing site |
| Collaboration | Walkthrough Labs stakeholders and developer |
| Scope | 12-slide product audit, 40+ mobile screens, dashboard, marketing site, prototype, design specifications and iterative releases |
| Status | Final design package delivered; developer handoff completed |
On the numbers: these describe the size and scope of the work — delivery outcomes, not claims about adoption or efficiency. Post-launch behaviour data was not available to me at the time of writing.
The problem
The person who sees the issue is rarely the person who resolves it
Facility teams move through rooms, equipment areas, courts, pools, grounds and event spaces while managers coordinate work across departments. A useful record needs to preserve more than a note. It needs to answer four questions quickly:
- What happened?
- Where is it?
- Who owns the next action?
- What evidence shows that the work is complete?
Walkthrough already had the right product idea: capture a photo or video, add visual context, send it to the right person and track the result. The challenge was that the interface did not consistently communicate the state of that process.
Account access was unclear. Home filters did not explain whether work was sent or received. Navigation states were easy to miss. Media controls could disappear against light images, and selected thumbnails competed with the send action. Empty states told users that nothing was available but did little to help them begin.
How might we make the path from field observation to verified completion clear at every step — without slowing down the people doing the work?The brief was broader than a visual refresh
Role & constraints
What I owned — and what I won’t overclaim
I owned the design process from the initial product audit through the mobile redesign, operations dashboard, responsive marketing page, client presentations, final delivery and developer handoff. The work had five constraints:
- Improve an existing product rather than redesigning a blank concept.
- Keep media capture at the centre of the field experience.
- Support frontline staff and managers without creating two disconnected products.
- Keep task ownership, status and completion language consistent across mobile and web.
- Turn a broad set of requirements into decisions and specifications a developer could implement.
Honest about the evidence: the engagement was client-led. I used the existing interface, product requirements, documented revisions and stakeholder feedback as evidence. I did not have direct access to end-user interviews or post-launch analytics, so I do not present client approval or delivery as proof of behavioural or business impact.
Discovery · Product audit
The product exposed features, but not enough state
I began with a structured audit and presented the findings in a 12-slide review. I grouped issues by the risk they created in the workflow rather than by individual screen.
| What I found | Why it mattered | Design response |
|---|---|---|
| Sign-in was the only visible entry path, with little explanation of how an organization user receives access. | A legitimate user could reach a dead end before experiencing the product. | Clarify password setup and recovery; identify invitation, request-access, self-registration and SSO as product decisions. |
| Home used ambiguous tabs and weak active states. | Staff could not quickly distinguish work they had sent from work assigned to them. | Make direction, ownership, status and next action explicit. |
| White controls appeared over light media and thumbnails competed with actions. | Users could miss controls or select the wrong evidence. | Separate controls from content and make selection states unmistakable. |
| Empty states and help paths offered limited guidance. | New users had no clear starting point or recovery path. | Add contextual guidance and a direct route into the primary action. |
| Fixed typography and weak contrast created accessibility risks. | Essential information and controls could be harder to perceive or operate. | Specify readable hierarchy, contrast, labels, target areas and meaningful interaction states. |
Across the audit, the same issue kept appearing in different forms: users needed to understand where they were, what had happened, who owned the work, and what should happen next. That became the foundation for the redesign.
Reframing
One service loop, not three products
I mapped Walkthrough as one connected service rather than a mobile app, a dashboard and a marketing site that happened to share a brand.
Identify→Capture→Annotate→Assign→Complete→Review
That framing produced three principles I could carry across every surface.
Direction, ownership, urgency, deadline and status should be understandable through language and hierarchy. Colour can support meaning, but it should not carry meaning alone.
People should see the media while they edit it, review what they selected before sending it, and understand the final state after submission.
Design decisions
Three decisions that carried the workflow
1 · Home became a work queue
The original Home screen presented categories without clearly explaining the work behind them. I replaced that structure with explicit All, Sent and Received filters and redesigned each walkthrough as a task card. The new hierarchy answers questions in the order users need them:
- What is the task?
- What is its status or urgency?
- Who sent it or received it?
- What progress or activity has occurred?
“Sent to” and “Received from” make task direction explicit. Status and priority use text labels supported by colour and icons; comments, media count, progress and date stay available but visually secondary. This also clarified the difference between platforms — mobile users need the next action, managers need the exception that requires attention.
The trade-off: a useful task card can hold status, priority, progress, recipient, comments, media count and date — but showing everything with equal emphasis makes it harder to scan. I solved that through hierarchy rather than by removing the information managers need.
2 · Capture and annotation stayed in context
Because media capture is the product’s central action, I placed the camera at the centre of persistent mobile navigation — staff can begin documenting an issue without first opening a menu or searching through existing work.
After capture, annotation controls open in bottom sheets. The photo stays visible while users adjust text, arrows, shapes, freehand drawing, size, colour and opacity. The decision was about feedback, not fashion: a separate settings screen would hide the evidence being edited and force users to remember the effect of each change; a bottom sheet keeps the action and its result visible together.
A reusable pattern: annotation tools share a common interaction model — sliders, colour controls, selection behaviour and confirmation states — reducing relearning for staff and giving development a clearer component model.
3 · Sending became a deliberate handoff
In an operational product, a fast submission is not successful if the wrong evidence reaches the wrong person. I structured the send flow around three decisions:
- Recipient — who needs to act?
- Completion window — when is it due?
- Title — what is the task about?
I added a media preview so users could confirm the selected photos or videos before committing. In the gallery, checkmarks, protected spacing and a contextual send action made multi-selection easier to understand, and the flow ended with a clear confirmation state so users never had to guess whether the walkthrough had been sent.
Why one extra step earns its place: the preview adds a single review step, but it reduces the cost of wrong attachments, wrong recipients and preventable rework. For this workflow, confidence was worth more than removing a tap.
Field to manager
Connecting field work to manager decisions
The dashboard extended the same task model for supervisors and organization administrators. Its information architecture organised walkthroughs, departments, team members, reports and administration around the operational questions managers need to answer.
A staff member captures and sends an issue on mobile → a manager sees it in the operational queue → the manager reviews evidence and comments → both roles see the updated state.The experience became one continuous loop
The dashboard table surfaces the assignee, reporter, progress, evidence, status and relevant actions. The detail view brings the media and metadata together so a manager can review the work without reconstructing the story from separate messages.
I carried the same status vocabulary and semantic colour rules across mobile and web. “Completed,” “in review,” “overdue” and other states should mean the same thing to the person doing the work and the person supervising it.
Designing for implementation
Documented releases, not one final screen
The work evolved through documented releases rather than a single final-screen presentation. The Figma file tracks three mobile releases, each with the rationale behind the components and flows so client feedback and developer questions could refer to intended behaviour — not only the visual treatment.
| Release | Change |
|---|---|
| v1.0.2 | Reframed Home as a task queue, clarified progress, and made notifications an explicit destination. |
| v1.0.3 | Improved gallery selection, added media preview before sending, and clarified download confirmation. |
| v1.0.4 | Connected annotation more closely to sending and refined comments, task details and completion states. |
Accessibility as an implementation requirement: I addressed visible risks through stronger contrast, persistent labels, colour-plus-text status cues, scalable hierarchy, robust target areas, and distinct selected, pressed, disabled, success and error states. I do not describe the product as WCAG-compliant from design files alone — final conformance requires implementation review and manual testing with VoiceOver, Dynamic Type, keyboard navigation, visible focus and text resizing.
Marketing
Extending the product story to the marketing site
I translated the same product model into a responsive marketing site. The page explained visual walkthroughs, task assignment, role-based collaboration and reporting using the same vocabulary and workflow shown inside the application — creating continuity across three moments:
- understanding the product before purchase;
- documenting work in the field; and
- supervising progress from the dashboard.
Handoff & delivery
Delivering behaviour, not just screens
The project did not end with polished mockups. I delivered the final design package, a connected prototype and annotated specifications, then joined a handoff meeting with the developer. We walked through:
- the capture-to-resolution journey;
- the relationship between mobile and dashboard states;
- the interaction intent behind key components;
- behaviour that could not be understood from static screens; and
- implementation questions affecting the core workflow.
This gave the client, designer and developer a shared understanding of what was essential and what could be adapted during implementation.
Results
What the engagement delivered
Delivery outcomes I can support
What the work delivered
- A 12-slide UX audit with prioritised workflow findings
- A redesigned iOS product with 40+ screens across documented releases
- A connected prototype covering the core capture-to-send journey
- An operations dashboard for walkthroughs, teams, departments, reports and administration
- Shared components, statuses and interaction patterns across mobile and web
- A responsive marketing site across desktop, tablet and mobile
- Annotated specifications and direct developer handoff
Results I should not claim
Without post-launch data
- “Issue-capture time dropped by X%”
- “On-time completion improved after the redesign”
- “Adoption or retention increased”
How success should be measured
If the client provides verified data later, these measures can turn the delivery story into an impact story without overstating what the design alone caused.
| Product goal | Metric |
|---|---|
| Capture issues efficiently | Median time and critical errors from opening the camera to successful submission |
| Preserve reliable evidence | Percentage of completed tasks containing the required photo, video or written evidence |
| Make ownership visible | Time from submission to assignment or acknowledgement |
| Close the loop | On-time completion, overdue rate and reopen rate |
| Help managers act | Time to find a previous repair or produce a board / reporting summary |
| Support field conditions | Upload failure rate and successful recovery from interrupted uploads |
Honest framing: these are delivery outcomes, not claims about adoption or efficiency. Post-launch behaviour data was not available to me at the time of writing.
Reflection
One operating model, many surfaces
The strongest lesson was that Walkthrough Labs was not three separate design assignments. The mobile app, dashboard and marketing site all depended on the same underlying questions:
What is the walkthrough? Who owns it? What state is it in? What evidence moves it forward?The questions every surface had to answer the same way
The work became stronger when I stopped treating navigation, task cards, annotation, reporting and marketing as isolated screens. I designed a shared operating model that could be expressed in a camera, a task card, a dashboard table and a developer specification.
A design is not complete when the final screen is polished. It becomes useful when the client understands the decisions, the developer understands the behaviour, and the product has a clear path to validation after launch.