KEY RESULT10/10 new participants understood the desktop requirement in the retest
Part 1: How I think
From one idea to first screens
1.1 / PROJECT CONTEXT
Access the file you need, while keeping control of what is accessible.
4Fimo was built for lawyers who need access to desktop files while away from their computers, without relying on cloud storage. Users approve specific folders on desktop, then retrieve individual files remotely. Retrieval depends on the desktop app staying running and connected; access is limited to approved folders, and fetched files remain available for 60 minutes while signed in.
My responsibility
As the sole designer, I translated the product’s technical requirements into flows, information architecture, interface states, and interactive prototypes. I worked with a product manager, two engineers, and a support lead, tested whether people understood the experience, and prepared the design specifications for handoff. My focus was making the conditions for access understandable at the moment users needed them.
1.2 / THE DESIGN MODEL: TWO ACTIONS
Approve on desktop. Retrieve when needed.
I organised the experience around two actions: choosing which folders can be accessed, then retrieving a file from those folders. Separating approval from retrieval makes the permission boundary explicit: approving a folder allows access to its contents without transferring them. These two flows gave the desktop and mobile experiences distinct responsibilities within one product.
Approve once, retrieve on demand.
Approval sets what’s in scope. Nothing is transferred yet.
1.3 / EARLY WIREFRAMES
Turning the two actions into a screen sequence.
The first wireframes mapped folder approval on desktop, browsing on mobile, and the request to retrieve a file. I kept them low fidelity to focus on navigation, the order of actions, and where users would encounter access requirements. This established the structure for the interactive prototype; usability testing would then reveal whether those requirements were understood.
Desktop approval: choose the folders that will be accessible remotely.
Mobile browsing: follow an approved folder to a specific file—Client Files → Case 124 → Contract.pdf.
Retrieval: map the request and download sequence, with space to explain desktop availability and temporary access.
Part 2: The final design
What users see and use
2.1 / VISUAL DESIGN SYSTEM
A calm, clear visual language for confidential work.
I defined a compact visual system to keep file lists easy to scan and interactions consistent across screens. Typography establishes hierarchy, neutral surfaces keep attention on file content, and colour highlights selection and status. For confidential legal work, the aim was a restrained interface with clear feedback about what users could do.
Typography
I used Inter for its clear letterforms and legibility in file lists and controls. The desktop hierarchy uses 36 px bold page headings, 20 px regular supporting text, and 16 px medium interface labels. This separates orientation, explanation, and action without introducing unnecessary type styles.
Colour
Purple (#8A38F5) highlights selected navigation. White surfaces and black text keep file lists clear. I kept the palette to one accent so the only things competing for attention are the file list and the access status.
THE FINAL DESIGN / INTERFACE DECISIONS
Final interface decisions are evidence of the response—not the research finding itself.
The images below show the later, high-fidelity 4Fimo designs. Rather than treating the screens as a gallery, I have organized them around the behaviors and explanations the research and technical constraints required. The usability results above relate to prototype testing; they should not be interpreted as performance metrics for every final visual screen.
2.2 / ORIENTATION AND DEVICE AVAILABILITY
Orientation and device availability
The entry experience needed to answer a prerequisite question immediately: is my computer available right now? Showing a device's online or offline status gives the user a reason for why remote actions may or may not be possible.
The Fetch Files hub then translates the underlying workflow into understandable destinations: explore authorized folders, search, track requested files, or review fetched files. It separates navigation from the state of the host computer.
The passcode screen identifies remote access as a deliberate, protected action. It avoids treating authentication as an invisible step and gives the user a clear indication of the security boundary.
The Explorer uses a familiar file and folder hierarchy. By presenting the approved desktop path and explicit Fetch and Share actions on each file, it makes the scope of access understandable without implying that the phone has a permanent local copy.
Retrieval involves waiting for a transfer between devices. A dedicated in-progress state acknowledges the request and tells users to keep the page open while the transfer completes.
The Fetched Files screen explains the temporary-storage model up front: files remain available for 60 minutes while signed in. The empty state provides a direct action instead of leaving users at a dead end.
Fig. 05 — Retrieval in progressFig. 06 — Time-limited access
2.5 / DESKTOP CONTEXT AND CONSISTENCY
Desktop context and consistency
The mobile experience depends on the desktop application; the desktop design is therefore part of the same system, not a separate visual exercise. My List supports file management while presenting the current connection status.
Received provides a consistent way to find incoming items. Across these views, persistent navigation and system visibility help connect the user's actions on one device to the conditions on the other.
Fig. 07 — Desktop My ListFig. 08 — Desktop Received
Design evidence: all eight final project assets are shown above in support of the research and rationale, at a reduced scale to keep the narrative central.
Part 3: Behind the scenes: the research
Why the screens look the way they do
3.1 / RESEARCH DESIGN
An evaluative study focused on whether the user's mental model matched the system.
A remote-access interface can appear straightforward when viewed as a sequence of screens. Yet a successful task depends on an accurate mental model of where files reside, what has been authorized, and which computer must be available. The research focused on the gap between a navigable interface and an understood service.
RESEARCH OBJECTIVE
Identify misunderstandings that could prevent people from completing an on-demand retrieval task, especially invisible prerequisites.
METHOD
Moderated usability sessions using an interactive Figma prototype. Participants worked through six tasks and were asked to think aloud.
SESSION FORMAT
Approximately 15–20 minutes per session, combining task observation with follow-up questions about what participants believed the product was doing.
INTERPRETATION
Qualitative, formative evidence was used to diagnose comprehension problems and inform design changes—not to estimate population-wide performance.
Questions guiding the evaluation
Would users recognize that remote access was dependent on an active desktop session? Could they distinguish approved desktop folders from files already available on their mobile device? Did the interface explain what would happen while a file was being transferred and how long it would remain accessible?
The clearest documented observation concerned the first question: participants initially did not understand that the desktop application had to be running. The other questions informed the interface requirements, but I do not present them here as independently validated findings.
3.2 / INITIAL FINDING: THE FAILURE WAS CONCEPTUAL, NOT NAVIGATIONAL
The critical failure was conceptual, not navigational.
In the initial moderated sessions, eight of eight participants failed to recognize that the desktop app needed to remain running for remote retrieval to work. Participants could encounter a plausible file-browsing experience without realizing that the files were still being served by their own computers.
This mattered because the dependency sits outside the mobile interface: a user might attempt retrieval while the desktop was asleep, disconnected, or no longer running 4Fimo. Without a clear explanation, they could interpret the resulting failure as a broken feature rather than a predictable system state.
The important research insight was therefore not simply “add a status badge.” It was that technical prerequisites had to be part of the product's information architecture and user-facing explanation, before a failed interaction occurred.
8/8
Initial participants missed the desktop-app dependency.
Finding documented in the earlier case-study version; interpreted as a comprehension problem within a small formative sample.
OBSERVATION
Users did not infer the dependency.
DESIGN IMPLICATION
Make device availability and the reason behind it explicit before and during file retrieval.
MEASURABLE RETEST QUESTION
After the changes, could a new participant correctly explain the desktop condition?
3.3 / HYPOTHESIS AND INTERVENTION
Make the invisible condition visible—and test whether that changes understanding.
Working hypothesis
If the interface showed computer availability and explained the requirement in context, people would form a more accurate understanding of how remote retrieval worked. The goal was to reduce confusion before a user tried to fetch an unavailable file.
Design intervention
I added clearer online/offline indicators and contextual messaging about the desktop app. Rather than separating the requirement into external instructions, the redesigned flow placed explanatory language near the actions that depended on it. Related interface states—authorization, transfer progress, and temporary availability—were also made more explicit so users could distinguish a prerequisite, an in-progress action, and a completed transfer.
3.4 / RETEST
Follow-up test
I evaluated the revised experience with ten new participants. All ten demonstrated understanding of the desktop dependency. This result provided direct formative support for the revised communication, though it did not establish improvements in long-term task performance or product retention.
10/10
New participants understood the requirement after the iteration.
The initial study and retest used separate groups. The result is a comprehension finding, not a statistically controlled estimate of effect.
The strongest outcome was better comprehension of a critical condition.
The documented research result was specific: participants in the follow-up usability test understood a requirement that had repeatedly been missed in the initial study. That supports the decision to foreground desktop availability and explanatory feedback within the interaction rather than relying on a user to discover the prerequisite independently.
The broader product was adopted by 22 law firms across Canada, and I presented 4Fimo at a legal-industry conference. Those are relevant project outcomes, but they cannot be attributed solely to the messaging intervention or the usability study.
What the study cannot establish
Small, qualitative samples are appropriate for identifying usability problems and testing candidate explanations. They do not measure retention, the frequency of real-world connection failures, causal uplift in conversion, or whether users retain the correct mental model months later. The original and follow-up sessions used different participants, which also limits direct before-and-after comparisons.
Questions worth studying next
A future evaluation could test whether users recover independently from an offline desktop, how they interpret expired files after 60 minutes, and whether the same understanding persists during real work rather than a guided prototype task. Behavioral task-completion data, error-recovery rates, and support requests would complement the formative findings.
Personal learning
This project changed how I approach complex product states. Security, device availability, and time limits may sound like engineering constraints, but they become UX requirements whenever they affect whether a person can successfully use the product. The most valuable design decision was making those constraints understandable at the moment they mattered.
DEFINE THE PRODUCT
01 — Idea & wireframes
Identifying the opportunity
4Fimo originally asked users to send files from their desktop to their phone in advance. For legal professionals working away from their desks, that meant predicting which documents they would need. The design opportunity was to support the moment when a file became necessary unexpectedly.
Choosing the product direction
I explored a flow built around Approved Folders: users choose which desktop folders can be accessed, then retrieve individual files remotely when needed. This gave the product a clearer direction while keeping the scope of access under the user's control.
Exploring flows and wireframes
I used flows and low-fidelity wireframes to work through the relationship between desktop setup and mobile retrieval. The sketches below separate two connected tasks: approving a folder at the computer, then finding and retrieving a file later. Establishing that sequence helped define the product before refining its interface.
The outcome of this stage was a clear product direction: approve folders on the desktop, then retrieve files when needed. The wireframes also had to account for a running, connected desktop application and a 60-minute file-availability window. These requirements carried into the detailed Figma designs.
IMAGE SPACE 02
Low-fidelity wireframes and the chosen product flow
DESIGN FOR DEVELOPMENT
02 — Figma design & developer handoff
Building the high-fidelity experience
With the direction established, I developed the flows into high-fidelity Figma screens and an interactive prototype. The mobile journey connected device availability, authentication, folder browsing, and retrieval; desktop views such as My List and Received supported the other side of that workflow.
The design used a familiar file hierarchy and clear Fetch and Share actions. Connection status explained whether the host computer was available, while progress and empty states helped users understand what was happening after an action.
IMAGE SPACE 03
High-fidelity Figma designs — mobile and desktop
Designing the states around each action
Preparing the product for development meant defining more than a successful path. I documented authorization, device availability, transfer progress, and expiry. The message below shows one of those decisions: explaining the 60-minute limit in the interface so users know that fetched files are temporary.
03 — The availability message explains the 60-minute limit and sets expectations for larger files before retrieval.
Preparing the developer handoff
I brought the screens, interactive prototypes, design specifications, and status diagrams together to communicate how the product should behave. Working with a product manager, two engineers, and a support lead, I connected the visual design to the actions and system conditions needed for implementation. These materials also provided a reference for QA.
IMAGE SPACE 04
Components, interaction specifications, and developer handoff
EVALUATE & REFINE
03 — QA & user testing
Reviewing implementation through QA
My role continued into QA coordination with the team. The designs, specifications, and status diagrams provided a reference for discussing implementation questions and checking whether the product communicated the intended behavior.
The key review areas followed the product's constraints: desktop availability, access to approved folders, retrieval feedback, and temporary file access. A screen needed to explain both what the user could do and why an action might be unavailable.
IMAGE SPACE 05
QA notes, annotated screens, and implementation feedback
Testing the user experience
I ran moderated usability sessions using an interactive Figma prototype. Participants completed six tasks and thought aloud during sessions lasting approximately 15–20 minutes. The sessions explored whether people understood how remote retrieval worked, especially its dependence on the desktop application.
Turning findings into design changes
In the initial sessions, participants missed the requirement to keep the desktop application running. I revised the onboarding and contextual messaging to make that dependency clearer. The online and offline states below show how the interface communicates both availability and the reason retrieval may not work.
04 — Online: the status indicator confirms that the host computer is available.
05 — Offline: an explanation connects the unavailable computer to the action needed—keeping the desktop application running.
I tested the revised experience with ten new participants. All ten understood the desktop dependency. This was a specific improvement in comprehension within the follow-up study; it did not establish long-term retention or performance across all product states.
IMAGE SPACE 06
Usability findings and before-and-after design changes
What changed and what I learned
The broader product was adopted by 22 law firms across Canada, and I presented 4Fimo at a legal-industry conference. These are project outcomes rather than results attributable solely to the usability changes.
The main lesson was that technical constraints become design responsibilities when they affect a user's ability to complete a task. Making those conditions visible and understandable was as important as designing the file-retrieval flow itself.
