Public Sector Purchasing App | Ana Zamfirache
Case Studies  /  Product Strategy · Enterprise SaaS · Public Sector

Modernising procurement for
government — from legacy
friction to one platform.

A cloud-native SaaS application built for government procurement teams at SAP — designed to reduce manual overhead, enforce compliance by default, and give Contract Managers and Legal Specialists a system that actually reflects how they work.

RoleProduct Lead — UX Strategist → PM
ClientGovernment & Public Organisations
CompanySAP
Timeline2022 – 2023
TypeSaaS · Procurement · Regulatory Compliance
1
Unified platform replacing
fragmented legacy systems
6
Core modules: from
onboarding to audit trails
2
Primary personas with
distinct role-based workflows
E2E
Full product ownership —
vision to validated delivery
01 — The Problem

Public sector procurement
was running on frustration.

Government procurement teams were dealing with a system that actively worked against them. Legacy software demanded heavy manual input for every step. User journeys were fragmented by unclear role definitions. New staff couldn't onboard without significant hand-holding. And every audit trail was a manual reconstruction exercise — in a context where compliance isn't optional.

What Staff Were Saying

"Procurement takes too long, is hard to navigate, and our staff doesn't know where to begin."

  • Legacy systems required heavy manual input at every stage
  • Fragmented user journeys — role responsibilities were unclear in the system
  • Audit trail and regulatory compliance were constant pain points
  • Low onboarding completion rates — high internal frustration from day one
  • No consolidated view of contract status or pending approvals
My Role as Product Lead

Owned end-to-end product delivery — bridging UX strategy and product management across a team of three designers. Defined the product vision aligned with compliance goals, led stakeholder engagement across legal, technology and operations, prioritised the backlog against measurable user and business impact, and managed Agile delivery through design validation and rollout.

This was the first project where my role explicitly shifted from Senior UX Designer to Product Lead — owning both the strategic and delivery dimensions simultaneously.

The Design Challenge

Build a modular, cloud-native procurement platform that reduces manual overhead without sacrificing compliance rigour — and design it to be intuitive enough that public sector staff at all technical levels can onboard and operate independently. Compliance must be built in, not bolted on.

02 — What, Why & How

A procurement platform
built for public sector reality.

Public sector procurement has constraints that commercial tools routinely ignore: fiscal accountability, transparency mandates, vendor diversity requirements, and regulatory frameworks that vary by jurisdiction. The platform had to work inside all of these — not treat them as edge cases.

Why This Platform

The strategic drivers behind the build

  • Efficiency and automation of repetitive procurement tasks
  • Transparency and accountability across all procurement decisions
  • Cost savings and fiscal responsibility through better visibility
  • Adaptability to evolving regulatory requirements
  • Vendor collaboration and supplier diversity support
How It Was Built

The capabilities delivered

  • User-friendly interface with role-based navigation
  • Automated approval and contract lifecycle workflows
  • Real-time analytics and procurement reporting
  • Compliance modules with embedded regulatory checks
  • Vendor management and collaboration tools
  • Security, data privacy, and full audit trail architecture
  • Interactive onboarding and in-app training support
  • Scalable cloud-native infrastructure
03 — User Personas

Two roles. Shared system.
Very different priorities.

The Contract Manager and the Legal Specialist represent the two dominant user archetypes in public sector procurement — one focused on operational throughput, the other on risk and compliance. Designing well for both required understanding where their needs diverged, and where the system had to serve both simultaneously.

User Role 01
The Contract Manager
Owns the end-to-end lifecycle of procurement contracts — from initial requisition through approval, vendor selection, award, and ongoing management. Measured on cycle time and compliance rate.
Primary Needs
  • Clear dashboard showing all contracts by status and priority
  • Automated workflow routing to reduce manual handoffs
  • Vendor comparison and selection tools with audit trail
  • Fast access to contract templates and approval histories
Core Frustrations
  • No consolidated view — status spread across email and legacy tools
  • Manual approval chasing with no visibility into bottlenecks
  • Compliance checks done retrospectively instead of inline
User Role 02
The Legal Specialist
Reviews contracts for legal risk, regulatory compliance, and clause accuracy before approval. Acts as the final gatekeeper before any procurement commitment is made. Risk-averse by professional necessity.
Primary Needs
  • Full contract detail with redline and version history
  • Inline compliance flags mapped to specific clauses
  • Clear record of every review and approval decision
  • Secure, traceable communication with Contract Managers
Core Frustrations
  • Contracts arriving for review without full context or history
  • No systematic way to flag and track legal concerns across contracts
  • Audit trail gaps creating liability exposure on completed deals
Design Implication

The Contract Manager needs speed and status visibility. The Legal Specialist needs depth and traceability. Both share the same data — but the interface priorities are opposite. Role-based dashboards weren't a nice-to-have feature: they were the architectural foundation of the entire product.

04 — Core Features

Six modules. Each solving
a distinct procurement failure.

The platform was designed modularly — so agencies could adopt features incrementally and the product could scale with their needs. But each module was designed as part of a coherent system, not as isolated tools.

Module 01
Role-Based Dashboards
Contract Managers see procurement pipeline and priority actions. Legal Specialists see pending reviews and compliance flags. Each persona gets the right view on login — no manual filtering required.
Module 02
Interactive Onboarding
Guided in-app onboarding with role-specific task flows. Reduced reliance on external training and addressed the low onboarding completion rate identified in research. Staff self-sufficient faster.
Module 03
Contract Lifecycle Automation
Automated routing for approvals, renewals, and expiry alerts. Eliminated the manual approval-chasing loop. Every contract moves through its lifecycle with full workflow support — no emails, no spreadsheets.
Module 04
Vendor Collaboration Portal
Suppliers submit bids, respond to queries, and share documentation through a dedicated portal. Reduces back-channel communication, creates a documented vendor interaction history, and supports supplier diversity goals.
Module 05
Real-Time Compliance Reporting
Compliance checks embedded inline throughout the procurement workflow — not retrospective. Legal Specialists see flags in context. Managers see compliance status on every contract without asking Legal.
Module 06
Audit Trails & Security
Every action, approval, and change logged automatically with timestamp and user attribution. Fully exportable for regulatory audits. Security architecture built to public sector data privacy standards.
05 — Key Design Decisions

Where strategy became
interface.

The competitive analysis and user research surfaced clear patterns in what existing tools got wrong. These four design decisions directly addressed the most persistent failures in the market.

Decision 01 Role-First Architecture Solves: fragmented journeys from unclear roles ↓ Time to task completion per role

Design the system around roles, not features

Every competitor tool was feature-first — presenting users with capabilities and expecting them to self-navigate to relevance. The Purchasing App was designed role-first: the system knows who you are and surfaces what matters to you. Contract Managers and Legal Specialists have distinct entry points, dashboards, and task priorities.

This wasn't just UX preference — it was a compliance decision. Role-based access controls and audit attribution require clear role definition. The UX and the architecture were designed together.

Role-Based Access Personalised Dashboard Context-Aware Navigation
Decision 02 Compliance by Default Solves: retrospective compliance checks and audit gaps ↓ Compliance exceptions at audit

Embed compliance into the workflow — don't ask for it at the end

Existing tools treated compliance as a checklist at contract completion. The Purchasing App embeds compliance flags inline throughout the procurement process — surfacing issues at the moment they can be fixed, not after the decision has been made.

The audit trail is automatic and continuous — not a separate module that someone has to remember to complete. Every action is logged. Every approval is timestamped. The system creates the compliance record as a byproduct of normal use.

Inline Compliance Flags Automatic Audit Logging Regulatory Workflow Gating
Decision 03 Contract List Report Solves: no consolidated contract status view ↑ Procurement pipeline visibility

One view to see every contract, filterable by anything that matters

The Manage Purchase Contracts List Report gives Contract Managers a real-time view of the entire procurement pipeline — status, value, expiry, assigned approver, compliance flag — all in one filterable, sortable surface. Replaces the email threads and spreadsheets that previously served as the "system of record."

Designed to SAP Fiori standards for platform consistency while optimised specifically for the procurement domain's data density requirements.

List Report Pattern Real-Time Status SAP Fiori Design System
Decision 04 Continuous Improvement Loop Solves: static systems that don't adapt to feedback ↑ Long-term adoption and satisfaction

Build the feedback mechanism into the delivery model

The product included a structured continuous improvement cycle — usage analytics, in-app feedback collection, and scheduled review loops with agency stakeholders. Post-launch iterations were scoped and prioritised using the same backlog framework as initial delivery.

In public sector contexts, procurement tools are used for years after initial deployment. Designing for adaptability was as important as designing for launch quality.

Usage Analytics Feedback Integration Iterative Backlog
View Figma Prototype →
06 — Delivery Process

Agile delivery across
legal, tech, and operations.

Product leadership in a cross-functional enterprise context means managing alignment as much as managing design. The delivery process was structured to keep legal, technology, and operational stakeholders moving in the same direction — without slowing down execution.

1

Discovery — Stakeholder Research & Competitive Analysis

Stakeholder interviews across legal, operations, and IT functions. Competitive analysis of existing procurement tools to identify market gaps and UX patterns to adopt or avoid. Defined the product vision and compliance requirements baseline.

Research
2

Persona Development & Problem Framing

Built Contract Manager and Legal Specialist personas grounded in interviews. Mapped current-state user journeys to identify where fragmentation and compliance failures were concentrated. Created a prioritised problem backlog.

Define
3

Product Vision & Backlog Prioritisation

Defined a modular product architecture aligned with compliance goals. Prioritised feature backlog using impact-versus-effort scoring across user value, business value, and regulatory necessity dimensions.

Strategy
4

Design, Prototype & Validation

High-fidelity prototypes in Figma, validated with Contract Managers and Legal Specialists across multiple iteration cycles. Applied SAP Fiori design system throughout for platform consistency and accessibility compliance.

Prototype
5

Agile Delivery & Continuous Improvement

Managed Agile delivery cycles from design validation through development handoff and QA. Established post-launch monitoring through usage analytics and stakeholder feedback loops for ongoing iteration.

Deliver
07 — What This Taught Me

Product leadership in
enterprise is a coordination problem.

This project was where I crossed from senior designer into product leader. The design skills were necessary but not sufficient. What the role actually demanded was the ability to hold a product vision while managing the competing priorities of legal, engineering, and operational stakeholders — and never losing sight of the user in that process.

Role-based design is a compliance architecture decision, not a UX preference. Designing for roles meant the system could enforce access controls, create attributable audit trails, and surface role-relevant compliance flags — all as byproducts of the UX structure. The best design decisions in enterprise products solve UX and architecture problems simultaneously.

Public sector users have been failed by software for so long they've stopped expecting it to work. The research interviews revealed a baseline of resignation — staff had built elaborate workarounds because the previous system made the real workflow impossible. Winning their trust required showing early that the new system was designed for how they actually worked, not how procurement theoretically worked.

Modular architecture requires more upfront design investment, not less. Designing a platform that could be deployed incrementally while remaining coherent as a system required more thorough information architecture work than a monolithic product. Every module had to work standalone and as part of the whole. This tension was the hardest design problem on the project.

Backlog prioritisation is a stakeholder alignment tool. The most valuable thing the priority framework did wasn't determine what to build first — it was create a shared language for legal, technology, and operations to negotiate trade-offs. When everyone uses the same scoring criteria, disagreements become productive instead of political.

Continuous improvement is only valuable if the feedback loop is designed from the start. Retrofitting feedback mechanisms into an already-deployed enterprise product is extremely difficult. Building analytics, feedback collection, and review cadence into the initial delivery model meant the product was always improving — not just at launch.

Outcome

A procurement platform
government teams actually use.

From legacy fragmentation to a single, role-based, compliance-first platform. End-to-end product ownership. Cross-functional delivery across legal, technology, and operations. A system built to last — not just to launch.

1
Unified platform replacing multiple disconnected legacy tools
6
Core modules covering the full procurement lifecycle
E2E
Product ownership from vision definition to validated delivery
Staff onboarding completion and system adoption versus legacy baseline

This project marked a professional inflection point — the moment where UX strategy and product management became the same role. Designing a procurement platform for government agencies means understanding that the people using it are accountable to citizens for how public money is spent. The quality of the tool is inseparable from the quality of the decisions it enables.

Need a product lead who can
own strategy and design?

Complex stakeholders, compliance constraints, enterprise users — the harder the context, the more end-to-end ownership matters. Let's talk about what you're building.

Connect on LinkedIn →
Previous
Previous

BRH- a SaaS application for the pharma industry

Next
Next

The Power of Conversion Rate Optimisation