File 03 Enterprise · Workflow Systems · Deloitte

Getting a proposal approved without a single email thread

Two enterprise applications for an international energy company: a proposal system that replaced approval-by-email-chain, and a sales-order migration that had to satisfy two incompatible ideas of what "easy to use" means. I was the lead designer on both.

Role: Lead designer
Client: International energy company (US-based)
Partners: Product owner, business stakeholders, dev team
Handoff: Full flows, documented in Zeplin

At a glance

What it is: Two enterprise applications for a US-based global energy company: a proposal approval system and an SAP→Appian sales-order migration.
The problem: Product approvals lived in email chains with no source of truth; the migration faced two incompatible ideas of "easy to use."
My role: Lead designer on both - working directly with the product owner, business stakeholders, and developers.
What I did: Designed an approval engine handling linear and non-linear paths, comments, rejections - plus the full notification system and its email copy.
Tested by change: Absorbed a mandatory mid-project overhaul when new stakeholders joined; the rebuilt flow came out more robust than the original.
The impact: The whole proposal lifecycle in one trackable system; a migration that kept users fast while landing on platform standards.

Part one - the proposal system

New-product proposals lived in email threads and chat messages. Documents were scattered across inboxes; nobody - including the approvers - could say where any proposal stood. There was no single source of truth, and the process depended on people remembering to forward things.

Working directly with the product owner and stakeholders, I converted requirements into features and wireframes, reviewed them with the people who'd actually use the system before committing to design, and delivered complete flows to developers through Zeplin.

Designing the approval engine

The heart of the system is an approval flow that handles how approvals actually happen - not how org charts pretend they happen:

Linear and non-linear paths - sequential sign-offs where order matters, parallel review where it doesn't.
Conversation built in - approver and requestor comments attached to the proposal, not lost in a side channel.
Real-world outcomes - requests for modification and rejection scenarios designed as first-class states, not error cases.
A complete notification system - every action in the lifecycle triggers the right notice; I designed the system and wrote the copy for each email it sends.

Illustrative recreation of the approval workflow screen: a proposal moving through initiation, business review, a parallel technical review with three approvers reviewing simultaneously, executive review and final approval, with an approver detail panel and comment thread alongside — Fig. 01 - Illustrative recreation (not the client's actual screens) - the parallel review stage, where three approvers work at once instead of waiting in a queue

Illustrative recreation of the proposal dashboard: summary tiles for total proposals, pending approvals, drafts and average approval time, above a sortable table of proposals with business unit, owner, current approver, status and priority columns — Fig. 02 - Illustrative recreation - every proposal in one trackable view, replacing the email-thread archaeology this system was built to end

The mid-project overhaul

Partway through, new stakeholders joined with mandatory requirements - and the approval flow needed a full redesign to absorb them. The client's key stakeholder brought the request to me, and I rebuilt the flow around the expanded reality. The reworked system came out more robust and more flexible than the original design: a structure that could absorb the next organizational change, not just this one.

Part two - the SAP → Appian migration

The client's sales-order application ran on SAP and needed to move to Appian, where the rest of their app ecosystem lived. The catch: Appian's established UX pattern was a rigid, step-by-step wizard - but the sales team was used to SAP's model of entering an entire order on one screen. Forcing either pattern wholesale would have broken either the platform's consistency or the users' speed.

I designed a hybrid: the platform's structure and design principles preserved, the users' single-screen efficiency retained where it mattered. Neither side compromised on what they actually cared about - which is different from what they initially asked for.

Illustrative recreation of the sales order creation screen: customer, shipping and billing information at the top, a single product line table with five order items below, and an order workflow, validation status and quick-navigation panel on the right — Fig. 03 - Illustrative recreation - one screen for the whole order, the SAP-era habit the sales team refused to give up, rebuilt on Appian's own component patterns

Outcome

The entire proposal lifecycle - submission, discussion, approval, tracking - in one trackable system that replaced email archaeology.
An approval engine flexible enough to survive a mandatory mid-project redesign, and the next one after that.
A migrated sales-order app that kept experienced users fast while landing inside the platform's design standards.

The client's actual screens are internal enterprise tools and can't be shown publicly - the visuals above are illustrative recreations of the flows, rebuilt from memory to show the shape of the work. Client identity and proprietary details withheld for confidentiality; scope and role as stated on my resume and verifiable on request.