Product case study Web and Tablet September 2026
I completed a fixed-scope audit for a small SaaS team whose founder handled onboarding personally. The team wanted new customers to reach useful work with less repeated help.
I delivered a written report, three clickable screen prototypes, prioritised recommendations, a proposed first sprint and a measurement plan. The client gave the engagement a 5.0 review on Upwork. My work ended at handoff; I do not have post-implementation results.
The product and client are unnamed here. I describe the work without customer records or product screenshots.
The question behind the audit
The product supports recruiting and planning work. Its users collect information in the field and return to it later when making decisions in the office.
The founder created accounts, sent access, explained features and sometimes prepared customer data. During our discussion, the founder described wanting to reduce this repeated work while keeping direct contact with customers. There was no product analytics in place at the time.
My task was to examine the path into useful work and recommend changes a small team could act on. That meant understanding which parts needed clearer guidance, which needed a behaviour change, and which parts of the service the team wanted to keep.
How I investigated it
I reviewed the web and tablet experiences as a new user. My inputs included eleven questions users had asked the founder, nine walkthrough videos, and a discussion with the founder and team.
The questions pointed to tasks worth checking. They were not enough to establish why people struggled or how often it happened. I followed the relevant paths in the product and tested the states around them: after an import, with navigation closed, in different device orientations, and when connectivity changed.
The report distinguished what I observed from what the client stated, what I inferred and what still needed testing. I also withdrew an early finding after an iPad re-check contradicted it.
Separating setup from the work that follows
I proposed two phases of onboarding.
Get your board ready describes the account state: the data and decisions needed to begin useful work.
Do the work describes what someone does for a particular trip or decision, in the field or in the office.
The founder confirmed that the same person often works in both contexts. The task changes, and there may be a gap before they need a particular feature again.
That helped me decide where guidance belonged. Instructions for a field task should remain available where the task happens. A first-run tour would not resolve the hidden controls I found later in those workflows.
For measurement, I proposed a candidate “board ready” state: a roster imported, a key prospect marked, no detected duplicate candidates awaiting review, and an event on the calendar. These conditions can be checked in any month, but I did not assume they were all necessary for every customer’s first useful task. The report recommends testing the conditions against later use and paid conversion before turning them into a customer checklist.
Three examples of the work
Make the starting task explicit. An empty player list directed the user to a “+” control. Upload was available, but the screen did not make it the clear starting task. I recommended a primary “Upload a roster” action opening the existing flow, with manual entry as a secondary option. I described the change with acceptance criteria and a clickable prototype.
Make an import result actionable. In a controlled import, duplicate candidates were detected, but the main iPad screen did not signal the waiting review work. The navigation count appeared only after I opened the review screen. I recommended an import summary with counts and a direct review action, plus a visible unresolved count. Finding possible duplicates and telling the user about them were separate problems.
Preserve what is already on screen. With two saved rosters open in the comparison view, I removed internet access while leaving the iPad connected to Wi-Fi. Both populated panels became empty. Opening either team separately still showed its saved roster. I documented that specific failure and expected behaviour; it did not demonstrate that the saved data had been deleted.
That last finding affected another recommendation. Comparison was hard to discover, but making its entry point more prominent would send more people into a workflow with an unresolved reliability issue. I made that release conditional on the fix. A clearer exit from an already open comparison could be delivered separately.
Turning the findings into a manageable plan
I grouped the recommendations around four priorities: a clear first action, reliable data and working state, discoverable field tools, and easier roster planning.
For the proposed first sprint, I separated bounded interface changes from issues that needed engineering investigation. The report asks engineering to confirm scope and capacity before committing. Suggested release windows use the recruiting calendar as planning context; they are not evidence of actual customer usage or expiry dates for the improvements.
The founder also raised the idea of having users upload their first roster during an onboarding call. I developed that into a pilot proposal: help the customer complete a relevant real task, then observe whether they complete another meaningful action independently before the trial ends.
For an account that already has data, the task should use what is there. Repeating setup just to complete a checklist would tell the team very little.
The measurement recommendation began with existing database fields and a small manual log. It distinguished account readiness, customer actions and the help provided. Analytics would use coach and account identifiers only, with no player-identifying data.
What the team received
The report connected each finding to a proposed next step. Defects included reproduction steps, actual and expected behaviour. Copy changes used current and proposed wording. Behaviour changes used user stories and acceptance criteria.
Alongside the three prototypes, the team received a priority map, proposed sprint scope, engineering questions, a guided-entry pilot proposal and a baseline measurement plan.
I did not interview end users or analyse usage data, so the audit cannot establish how many customers encountered each problem. Android, iPhone and admin workflows were not reviewed. Scheduling and calls received limited checks and separate notes, rather than a complete workflow audit.
The confirmed result is the completed handoff and the client’s positive review. Whether the recommendations improve independent use, conversion or support demand remains to be measured.
What I wanted the team to have was a practical starting point: specific changes they could assess, uncertainties they could investigate, and a way to check what happened afterwards.
Where this work lives
This case exists as the artifact on Upwork – Onboarding & Activation Audit for a B2B SaaS (Web + Tablet)
Need a candid, structured review of your product’s journey — before your users find the problems for you? I’m open to contract and fractional PM/PO engagements.
Leave a Reply