HIRO WAILANI
HomeAboutDownload Resume

Enterprise Structural Alignment System

A leadership-facing system that surfaces structural risk across large-scale initiatives. Built
as a fully interactive prototype.
My Role: Product & Systems Designer
Scope: Enterprise operational tooling
Concept to working prototype
Focus: Systems-thinking in an enterprise context

Explore the working system

Add initiatives, log updates, track structural drift week over week
View Live Prototype
Alignment does not fail suddenly.

It degrades gradually.
Large product initiatives rarely fail because teams lack execution.
They fail because structural misalignment goes undetected until it's too late.

Context

The Problem

Existing tools optimize for execution tracking, not structural alignment.
This creates a gap:

Teams can look healthy on paper while coordination risk increases.
Observed Patterns:
  • Ownership is not consistently re-evaluated as scope evolves
  • Dependencies expand without clear visibility across teams
  • Confidence remains high despite structural change
  • Alignment relying heavily on meetings and verbal updates
Expected Outcomes
  • Surface structural risk earlier
  • Improve ownership clarity
  • Reduce dependency blind spots
  • Enable earlier leadership intervention

What the System Does

Confidence vs. structural change

A dual-line chart tracking confidence trend against structural change frequency week over week. Divergence between the two is the core risk signal.

‍Initiative deep dive

Per-initiative timeline view showing phase, structural changes, external gating, update status, and escalation intent in a single surface.

Audit log with authorship

Every change is logged with author, timestamp, and a contextual note. Creates an accountable paper trail of structural decisions, not just outcomes.

Escalation intent

Each initiative carries an explicit escalation signal — Monitor, Watch, or Escalate. Teams declare intent, not just status. Leadership sees posture, not just health.

Alignment stability score

Aggregated across all active initiatives — ownership stability, confidence trend, structural change rate, and update status rolled into a single system-level read.

Week-over-week reporting

Initiatives are logged by reporting week, allowing the system to surface drift over time rather than just point-in-time snapshots.

How This Design Evolved

Three directions explored gave insight into the current model, insights are:
Abandoned

V1 - Activity feed model

Surfaced all team actions in a timeline. Felt comprehensive but created noise. Users couldn't separate signal from routine updates.
Updated

V2 - Health score dashboard

Reduced to 3 aggregate scores (ownership, dependency, load). Cleaner, but abstract takes away the specific signals that made risks actionable.
Current

V3 - Structural layer signal

Separated overview from deep-dive. Overview surfaces risk; the timeline view shows how it developed. Inspection without prescription.
What I learned from V1 and V2 (Version)
"This is just another Jira dashboard. Why would I open this and integrate my data here when I already have this set up?"
- Feedback during informal review of V1 prototype
That reaction/feedback gave me a moment to pause and take a step back. I asked myself, "what does this surface that nothing else does and how can this impact teams in real-time?" The answer was structural drift overtime, not tasks, or status, but the signal that coordination is misaligned before deadlines are missed. V2 tested whether scores alone could carry that, but removed the specificity that made it useful. V3 restored the detail while keeping the overview lean.

Key Design Decisions

Several key decisions shaped the direction of this system:
Why time-series instead of snapshots?
A snapshot that shows "3 at-risk initiatives" is less actionable than seeing that number was 1 two weeks ago and has been rising.
Drift is the signal; the current state is just the latest data point.
Why no remediation features?
Early versions included an "assign owner" action inline. Removed it. Adding execution to an observation tool muddied the
purpose and introduced governance complexity the system wasn't designed to handle.
Why confidence score alongside structural signals?
Structural health and team confidence often diverge — that gap is itself a signal. A team reporting high confidence while
ownership is fragmented is worth flagging to leadership.

System Model

The system does not replace execution tools.
It observes structural signals across initiatives and surfaces divergence before deadlines are missed.

Structural Alignment Overview

Aggregates structural signals into a single view of system health.
  • Ownership stability
  • Dependency volatility
  • Coordination load
This provides a high-level understanding of where alignment is degrading.

Initiative Deep Dive (Timeline & Ownership)

Focuses on how a single initiative evolves over time.
  • Ownership changes
  • Dependency additions
  • External gating events
  • Confidence movement over time
Ownership is treated as a changing signal, not a fixed attribute.

This makes structural drift visible, not only outcomes.

Dependency Network

Maps relationships across teams and systems.
  • Active dependencies
  • Constraints and blockers
  • Cross-team coordination
This shifts visibility from isolated initiatives to system-based interaction.

Intended Audience

Primary
Engineering Director, 8 active initiatives
Finds out initiatives are misaligned during quarterly reviews — too late to course-correct without delays. Doesn't trust status reports because they're self-reported.
Secondary
Senior PM, 3 cross-team programs
Spends 40% of time in sync meetings that exist only to surface information that should be visible structurally. Wants fewer meetings, not more dashboards.

Constraints

Audience
Engineering leads and PMs at companies with 5+ cross-functional initiatives running simultaneously
Scope Limit
Observation only — no task assignment, no notifications,
no integrations with existing PM tools
What I Excluded
Team-level dashboards, reporting exports, and anything that competes with Jira or Linear
Design Question
Can structural misalignment be made visible before it
becomes delivery risk?

What This Demonstrates

This project reflects how I approach product design in complex environments:
  • I design systems that remain resilient under delivery pressure and evolving scope
  • I model system behavior over time, not just interface states
  • I consider adoption resistance and governance implications early
  • I prioritize structural clarity over aesthetic novelty

Personal Reflection

Designing for organizational systems requires observing behavior across teams rather than individual user flows.
Structural alignment is often invisible until it fails.
Design can make those signals visible.
Campaign Case StudyCross-Platform Case Study