Project Name

UNOPS Integrity Portal

UX Design UI Design Portal Design Atomic Design Content Strategy
Link to Project insert-link-here
Year 2024
Role UX Designer

The Challenge

How do you design a platform for reporting workplace misconduct when the act of visiting the site itself could put someone at risk?

UNOPS needed a digital portal where staff could report ethical violations, fraud, and abuse. But this wasn't a typical corporate form. This was a lifeline for people in vulnerable situations—potentially accessing it from shared computers in field offices, internet cafes, or over the shoulder of colleagues.

The design challenge wasn't just about usability. It was about protection, dignity, and clarity in moments of crisis.

Understanding the Context

I started by mapping the scenarios where this site would actually be used:

The environment:

  • Staff in field locations with limited private access to computers
  • Shared workspaces where screens are visible to others
  • Public internet cafes in countries where UNOPS operates
  • Mobile devices in areas with spotty connectivity

The emotional state:

  • Users who may have just experienced harassment or abuse
  • Individuals putting their careers at risk to report wrongdoing
  • People already in distress, not in a state to parse complex legal language
  • Fear, anxiety, and hypervigilance about being discovered

This reframing shifted everything. The site couldn't just be functional—it needed to be a safe space, even in unsafe physical spaces.

Design Principles: Intentional Restraint

1. Camouflaged by Design

Rather than creating a modern, eye-catching interface, I advocated for something deliberately unremarkable. The visual design intentionally mimics UNOPS internal documents and standard forms.

Why it matters: Someone glancing at a screen sees what looks like routine administrative work—not a whistleblower report. This "boring by design" approach creates privacy through anonymity.

2. Cognitive Kindness

Users filling out misconduct reports may be traumatized, anxious, or working under time pressure. I pushed for:

  • Short, direct sentences instead of legal jargon
  • Clear section headings that telegraph what's being asked
  • Progressive disclosure—showing only what's needed at each step
  • Plain language explanations of what happens after submission

The principle: Don't make someone who's already suffering work harder to be heard.

3. Visual Hierarchy for Scanning

Even though the design is intentionally plain, information architecture matters. I structured the interface so users can:

  • Quickly scan to understand their options
  • Find the reporting path that matches their situation
  • Understand confidentiality protections at a glance
  • Exit quickly if needed (though we avoided a panic button that could itself draw attention)

Bridging Design and Development: Atomic Design as Project Structure

One of the most interesting challenges was coordinating work across a small, distributed team. We were working in Atlassian Jira, but the typical story structure wasn't mapping well to our component-based design approach.

I adapted Brad Frost's atomic design methodology—not just as a design system, but as a project management framework.

The Structure:

Initiative Level: Website UI Front-End Development (WBLOWER-61)

Epic Level:

  • Components Epic (WBLOWER-47) - Atoms & Molecules: Buttons, accordions, cards, typography
  • Blocks Epic (WBLOWER-60) - Organisms: Topbar navigation, FAQ accordions, footers, page headings
  • Pages Epic (WBLOWER-18) - Templates & Pages: Landing, Resources, FAQ, Report pages

Story Level: Individual components and blocks as discrete tasks

Why This Worked:

For developers:

  • Clear dependencies (atoms → molecules → organisms → templates)
  • Reusable components were built first, preventing duplication
  • Logical build sequence that matched how React/component libraries work

For the PM:

  • Visibility into progress at multiple levels
  • Could report status by page, block, or component
  • Easy to identify blockers in the dependency chain

For me:

  • Design specs aligned with development tickets
  • Could hand off work in logical chunks
  • Maintained design consistency through component thinking

For stakeholders:

  • Progress was tangible ("The FAQ page is 60% complete" meant something specific)
  • Could prioritize pages without disrupting component work

This wasn't just project management—it was translating design thinking into a language developers and stakeholders could plan around.

Atomic Design Structure for Jira

The visual representation below shows how atomic design principles were adapted to structure the development workflow in Atlassian Jira, organizing components from atoms to pages:

Atomic Design: From Concept to Implementation

The atomic design hierarchy applied to the Integrity Portal, showing how each level translates from concept to actual implementation:

Atoms

Concept

Atoms - Basic building blocks

Applied to Portal

Site Atoms - Buttons, typography, form inputs
Molecules

Concept

Molecules - Simple component groups

Applied to Portal

Site Molecules - Form fields, card components
Organisms

Concept

Organisms - Complex UI components

Applied to Portal

Site Organisms - Navigation, accordions, page headers
Templates

Concept

Templates - Page layouts

Applied to Portal

Site Templates - Page layouts and structures
Pages

Concept

Pages - Final implementations

Applied to Portal

Site Pages - Final page implementations

Mapped to Jira Project Structure

The complete Jira ticket structure showing how atomic design levels correspond to epics and stories:

Jira project structure mapping atomic design to tickets

Collaboration & Iteration

Working with a small team meant wearing multiple hats:

With developers:

  • Created detailed component specs in Figma with annotations
  • Held regular sync sessions to discuss technical constraints
  • Made real-time adjustments when implementation revealed design assumptions

With the product manager:

  • Advocated for the "intentionally plain" design approach (not always an easy sell)
  • Helped prioritize features based on user scenarios rather than stakeholder requests
  • Balanced accessibility requirements with the need for visual discretion

With UNOPS stakeholders:

  • Presented the safety rationale behind design choices
  • Demonstrated how restraint in design could build trust with vulnerable users
  • Navigated requirements for legal compliance while keeping language accessible

What I Learned

  • Design isn't always about standing out. Sometimes the most responsible design decision is to blend in. Understanding context—physical, emotional, political—matters as much as understanding users.
  • Project structure is a design problem too. The atomic design framework gave our team a shared mental model. It made handoffs cleaner, reduced miscommunication, and helped everyone see how their work fit into the whole.
  • Empathy requires specificity. It wasn't enough to say "users might be stressed." Mapping actual scenarios—the field office, the internet cafe, the moment after harassment—made the design constraints real and actionable.

Reflections

This project reinforced something I deeply believe: design choices are ethical choices. Every decision about color, language, layout, and interaction carries implications for someone's safety, dignity, and ability to seek help.

The UNOPS Integrity Portal won't win design awards for visual innovation. But if it helps even one person report misconduct without fear, if the plain design lets someone access it safely from a public computer, if the simple language makes a traumatic process slightly less overwhelming—then it's doing exactly what it should.

Sometimes the best design is the one you don't notice.

View the live site at integrity.unops.org