Anonymized Case Study
Engineering platform
A clearer path through complex document work
As UX/UI Designer, I researched professional document work, designed a staged prototype, and tested it with small samples. The work produced a high-fidelity prototype and implementation-facing UX guidance.
- Situation
- Dense metadata, mixed information levels, and established expert conventions made document work difficult to modernize.
- My role
- UX/UI Designer responsible for research, interaction design, prototyping, validation, and development alignment.
- Contribution
- Focus Area
- Complex operational UX
- Period
- March–June 2026
- Verified change
- Small-sample prototype validation supported a staged creation workflow and gave product and development stakeholders direction for implementation decisions. It does not establish a production outcome.
Early evidence
A staged prototype clarified complex document work
This recreated workflow presents the proposed structural change without reproducing client UI. In a two-participant prototype check, both people rated the staged direction highly for clarity and confidence and said they could complete it independently.
Starting experience
One task, many competing fields
Recreated design direction
Four clear stages
- 01ProjectConfirm inherited information
- 02DocumentDefine document information
- 03FileMake naming consequences visible
- 04ReviewCheck before completion
Decision atlas
Three decisions clarified the work without removing expert control
The direction staged creation, made reuse easier to find, and separated shared defaults from exceptions and access states.
Consequential decision
Stage creation instead of showing everything at once
The problem
Professional users could handle detailed information, but the existing flow presented overlapping names, numbers, and metadata together without a clear order or explanation of their consequences.
Evidence and reasoning
Three initial interviews surfaced overload, duplicate entry, and uncertainty about which values affected the final document. The need was clearer sequencing, not fewer expert decisions.
Design response
I designed a four-step process for data entry: project, document, file, and review. In the proposed flow, file naming was visible, duplicated entry was reduced, and people could see how each selection affected the process before completion.
Proof
In a two-participant prototype check, clarity was rated 4/5 and 5/5; both participants rated confidence 5/5 and recommendation 10/10. Initial recommendation ratings were 7/10, 6/10, and 8/10 across three interviews. These small samples indicate direction only; they are not statistically meaningful.
See the recreated workflow and ratings ↑ ValidatedConsequential decision
Make reuse easier to find
The problem
Finding a starting file depended heavily on remembering technical names and a large folder tree, even though work could begin in several ways.
Evidence and reasoning
Three cross-discipline validation sessions indicated that people could retrieve files using familiar names and numbers. They also reinforced that reuse was a routine part of the workflow and that a complete information-architecture replacement was not the immediate priority.
Design response
I kept the familiar structure and added search, filters, useful context, and clear paths for templates, existing files, and previously created documents.
Proof
The recreated retrieval model shows the proposed change: familiar names and numbers become search inputs rather than the only route through the structure.
Consequential decision
Separate shared defaults, exceptions, and access states
The problem
Project and document information were mixed, while exceptions and restricted projects needed different handling.
Evidence and reasoning
Domain interviews and two phase-four validations supported clearer project/document separation and familiar preview-and-open behaviour. Access rules still required product and security decisions.
Design response
I proposed shared project defaults, controlled document exceptions, separate technical and output data, and a limited-access preview.
Proof
The recreated information model distinguishes the proposed data path from the access decision that remained with product, security, and development stakeholders.
Results
What changed
The work produced and checked a proposed direction for document creation, template retrieval, project navigation, metadata, permissions, and reusable interaction patterns. Research findings and prototype checks gave product and development stakeholders a clearer basis for implementation decisions.
Evidence boundary
What this does not establish
The samples were small and may include repeat participants. They do not establish production status, adoption, business impact, time savings, or reduced errors. All visuals are recreated, not original client material.
Collaboration and constraints
UX direction shaped with the team, close to implementation
My responsibility
I planned and conducted interviews, synthesized findings and requirements, designed and maintained interactive prototypes, ran validation, documented decisions, and prepared implementation-facing UX guidance across four phases.
Wider team
Product stakeholders set priorities, developers assessed feasibility and owned implementation, domain experts explained professional conventions, users tested proposals, and security and access stakeholders owned policy decisions.
Material constraints
The design had to serve occasional and frequent users, preserve useful legacy conventions, scale to large project structures, respect confidential access states, and improve incrementally while implementation planning was already moving.
Start a conversation
What has become fragmented, difficult to use, or hard to decide?
Tell me briefly about the situation. I’ll reply with an initial perspective and a sensible next step.