Part 1 of 2 · Product design

The document is where the work lands

I explored how contract work could become focused on a phone without losing the record that makes each decision understandable.

The screen became smaller. The obligation did not. Reviewers still needed evidence before approval. Requesters still needed a paced path through document creation. Coordinators still needed to see who had to act next.

This was exploratory mobile work. Names and agreement details shown here are fictional. I do not claim launch or measured outcomes.

See the key decisions Try the prototype View part 2
Mobile contract record with current status, key facts, and approval context
The record remains the anchor before and after a focused task.

45 second summary

What I designed and what this story proves

Problem
Complex contract tasks had to fit a phone without stripping away decision context.
Ownership
I mapped the journeys, designed the interaction model, connected the prototype, and explored the visual direction.
Scope
Approval, document creation, signature setup, and signature monitoring.
Evidence
Connected source frames, explicit design tradeoffs, and a working browser prototype.
Series
Part 1 of 2. Part 2 proves the executable transition rules.
Status
Exploratory work with fictional names and agreement details.
Limit
I do not claim launch, user research findings, adoption, or measured business outcomes.
Editorial composition of mobile contract screens surrounded by journey sketches and design notes
Editorial composition of the three journeys. Screen evidence below comes from the working prototype.

Act 1 · Context

A small screen, an unchanged obligation

A contract record carries properties, clauses, attachments, versions, comments, workflow history, required questions, and signature progress. Mobile design did not remove those layers. It changed the moment each layer should appear.

What must be visible before a person acts, what can wait, and where should the person return after the action?

Professional services agreement

Awaiting approvalVersion 4 · Updated today
  1. 01
    Current state

    Ownership, workflow position, and the next available action

  2. 02
    Decision context

    Required questions, value, risk, and responsible reviewer

  3. 03
    Document evidence

    Clauses, attachments, versions, and comments

  4. 04
    History

    Audit events, previous decisions, and signer timestamps

The contract recordI treated these layers as one record. Mobile hierarchy decides when each layer deserves attention without pretending any of it disappeared.

Act 2 · Architecture

Three departures from the document

The information architecture exposed one pattern across all three journeys. A person left the record for a focused task, completed an action, then returned to a record whose state now meant something different.

Approval returned with an audit event. Creation returned to a new agreement. Signature returned with responsibility, waiting, or completion made visible.

Shared anchorContract record

Context before action. Meaningful state after action.

Approval

  1. LeaveOpen assigned task
  2. ActRead context and answer required questions
  3. ReturnApproved record with a new audit event

Creation

  1. LeaveChoose a template
  2. ActComplete focused steps and select stakeholders
  3. ReturnNew document record ready for review

Signature

  1. LeavePrepare a request
  2. ActOrder recipients and monitor responsibility
  3. ReturnRecord showing waiting, declined, or complete
Three departures from one recordThis retrospective model condenses the connected source frames. It shows the structural conclusion rather than claiming to be the unavailable original export.

Act 3 · Primary decision

Context has a timing problem

Fully expanded records made the action compete with everything. Fully collapsed records concealed the reason for the decision. I chose a summary first sequence that led with current and changed facts, then revealed required context where it became consequential.

Approval became the strongest test. The action stayed unavailable until the reviewer accepted responsibility and completed both required inputs. The cost was one more deliberate step. The benefit was a decision whose context remained visible.

01
Compact agreement summary with current status and key contract facts
Summary first. Current facts lead while the full record remains reachable.
02
Approval context form with required information still missing
Required context becomes visible at the moment it blocks a decision.
03
Approval context form completed and ready for review
The action becomes available only after both requirements are complete.
Summary first, then decision contextThe source work explored expanded, collapsed, and compact treatments. The implemented sequence shows the chosen principle with real states instead of illustrative placeholders.
01

What should lead?

Choice
Current and changed facts
Cost
Secondary details need one more action
Open risk
A reviewer may still need the complete document
02

When can approval continue?

Choice
Only after required context is complete
Cost
The workflow can take longer
Open risk
Validation rules still need product definition
03

Where should completion land?

Choice
Back inside the updated record
Cost
The return state needs careful continuity
Open risk
Concurrent changes need server conflict handling
Decision logEach choice solves a hierarchy problem and introduces a cost. The open risk remains visible instead of becoming a fabricated outcome.

Act 4 · Generalization

Completion changes the place I return to

The same rule shaped creation and signature without forcing those journeys into the same interface. Creation needed pacing, progress, validation, and a resulting record. Signature needed visible order, current responsibility, reminders, and terminal states.

The shared behavior lived at the boundary. Each focused task returned to the contract record with a state change a person could understand.

Agreement record with approval reflected in its workflow timeline
Approval returns to an updated workflow and audit state.
New agreement record created from a completed local draft
Creation returns to the document that now exists.
Agreement record with every signature complete
Signature returns to responsibility and completion inside the record.
Completion changes the recordThese real implementation states make the shared rule visible. Success is not a detached message. It changes the document a person returns to.
Mobile template browser with searchable agreement choices
Creation leaves the document list through a deliberate template choice.
Mobile agreement form with a focused validation summary
Pacing keeps validation beside the step that needs correction.
Resulting agreement record after document creation
The new record becomes the destination, not a detached success screen.
Signature request with recipients in an explicit order
The request makes responsibility visible before sending.
Signature request waiting for the current recipient
The return state shows who is responsible now.
Completed signature request inside the agreement record
Completion closes the loop inside the same record.

Part 2 shows how I turned these return rules into executable behavior.

Continue to design engineering

Act 5 · Honest boundary

The interface was still unresolved

The source file ended with one visual study, not a complete product system. It tested more editorial type, larger controls, more spacing, and a stronger primary action. I carried those ideas into the working implementation while keeping the source status clear.

Connected behavior
Working template browser in the rebuilt mobile contract prototype

Source study recorded in Figma

One screen tested a more editorial direction

  • Larger serif headings
  • More generous spacing
  • Rounded search and stronger selection
  • Off white surfaces with a clear primary action
Overhead photo of hand drawn mobile approval wireframes on paper
Early paper exploration. Texture for process, not a measured deliverable.

The original polish study image could not be recovered through the available export quota, so I am not presenting a reconstruction as source evidence.

The visual direction remained openThe source file ended with one unfinished visual study. I carried its larger type, generous spacing, stronger search, and clearer action hierarchy into the working prototype without calling it a completed design system.

Open questions

What still needed product definition

  • Who can transfer approval responsibility and when?
  • How should cancellation and reopening affect the audit record?
  • Which questionnaire rules come from each workflow configuration?
  • How should concurrent offline edits resolve against server state?
  • Which signature roles and permissions belong on mobile?
  • What measured outcomes would prove the model in production?

Every action returns to the record

I did not remove contract complexity. I gave it a sequence.

The result is a coherent model for mobile contract work: preserve the record, focus the task, and make completion visible where the work continues.

Hiring a senior product designer for complex workflows? Send me the role and the product problem.

Contact Try the prototype Return to selected work