Agreements at the Department of State App Design

Project Overview

The Diplomatic Technology Enterprise Agreements Application supports the full lifecycle of an agreement from the customer’s first request all the way to service teams delivering the final approved document. Each group experiences the workflow differently: customers need clarity and transparency, the intake team needs tools to manage and triage requests, and service teams need something structured enough to keep everything compliant and on track.

---

Project Type: Application Design

My Role: UX/UI Designer & Developer (supported by Software Engineer, Project Manager, & Customer Engagement Team)

Tools: Figma, Figma Jam, & Microsoft Power Apps

Duration: 5 months (2025)

*Note: This was a conceptual project pitched to DoS. Images and content does not contain any classified information.

Target Users

• Internal Staff (Legal, Contract Managers, Business Analysts)

• External Partners (Vendors, Clients, Agencies requiring agreements)

• Executives / Approvers (Decision-makers who provide final authorization)

Challenge

The initial application was a manual fragmented agreement management process with a centralized digital platform. Departments were juggling email threads, manually edited Word docs, outdated templates, and unclear approval chains that forced legal and business teams into constant firefighting.

The current agreement process is captured in the diagram below:

• Customers (external partners, agencies, or vendors) didn’t always know what information to provide or where their agreement was in the process. They’d submit something and then… wait. And guess. And email.

• The intake team became the “traffic control tower,” manually tracking requests, answering status questions, and trying to interpret incomplete documents. If a requester forgot a key detail or used an old template, the intake team had to chase it down.

• Service teams (legal, analysts, program staff) worked with whatever came in. That meant juggling email threads, inconsistent formatting, and a constant hunt for the “real” version. Approvers, meanwhile, got documents without context or history.

Research & Solution

Research Method: Stakeholder Interviews & Collaborative Workshops

To understand the operational realities behind the agreement and service request process, the research approach focused on qualitative discovery with the people closest to the work. Rather than relying on assumptions or documented process maps alone, the method centered on stakeholder interviews and cross-functional workshops to surface how work actually happens versus how systems assume it happens.

Solution

A centralized intake workflow coordinates customer requests, intake triage, service team collaboration, and approvals—reducing friction while preserving context and accountability.

Key System Behaviors

• Single source-of-truth agreement case

• Parallel reviews (no sequential bottlenecks)

• Full audit trail of decisions and changes

• Automated status updates and notifications

The future state agreement process is captured in the diagram below:

Design System & UI Components

UI Components

Key UX Requirements

The following UX requirements were derived from stakeholder interviews, workflow workshops, and service blueprint analysis. Each requirement directly addresses operational pain points surfaced during research.

Development

Defining the Information Architecture

I started by creating the sitemap of the existing app. Then, I brain-dumped my changes on top of the existing sitemap.

User Flow Maps

Then mapped the approval flow.

Wireframes & Prototypes

Usability Testing

Delivery

Project Retrospective