A Global IT Intranet Needed a Clear Front Door

The broader initiative covered a global internal IT environment, but this part of the work focused on the dashboard employees would use for onboarding and day-to-day requests.

The existing process placed too much administrative burden on employees and IT staff. Common tasks were distributed across different pathways, important actions competed with lower-priority information, and the interface did not clearly reflect how people actually used the system.

The dashboard needed to become a practical front door: clear enough for a new employee, efficient enough for frequent users, and structured enough to support the larger intranet behind it.

The design problem was not adding more functionality. It was deciding what deserved attention first.

One Week in New York With the CTO and His Directors

I spent a week on-site in New York City working directly with the CTO and members of his leadership team. The room included people responsible for different parts of the IT organization, each with a legitimate view of what the dashboard needed to support.

We worked through the product in real time on whiteboards. We mapped employee needs, common service requests, onboarding steps, ownership, escalation paths, and the relationship between summary information and deeper workflows.

The value of the workshop was not simply gathering requirements. It created shared agreement among decision-makers before design and development began.

The Dashboard Became a Layer of Prioritized Actions

The whiteboarding sessions made it clear that the dashboard could not treat every task equally. Employees needed fast access to the actions they performed most often, while less frequent or more complex tasks could remain available without dominating the page.

I organized the experience around a small set of high-value entry points supported by status, context, and secondary navigation. This reduced the amount of searching required and made the system feel less like an intranet directory and more like an operational tool.

The interface was designed to surface the most useful information at the right level, then allow employees to move deeper only when necessary.

A Dense Enterprise Tool Needed to Feel Immediate

Internal enterprise tools often accumulate complexity because every department has something important to add. The interface had to acknowledge that complexity without exposing all of it at once.

I used clear hierarchy, modular panels, prominent task areas, and restrained visual styling to create a dashboard that felt focused rather than overloaded. The design emphasized usefulness over decoration and made the most frequent workflows visible without forcing users through a deep navigation structure.

Primary actions and high-value information were elevated into a clear dashboard hierarchy.

Request and support flows were structured to minimize the time employees spent navigating administrative tasks.

Secondary screens extended the same design language without losing the dashboard's sense of clarity.

I Left the Workshop, Built the Front End, and Returned With Something Real

Once the workshop established the product direction, I moved directly from concept into execution. I designed the interface, translated the layouts into working front-end code, and tested the experience as an actual browser-based product rather than a set of isolated screens.

This changed the quality of the handoff. The internal team did not need to reconstruct spacing, states, hierarchy, or responsive behavior from static mockups. They received a functioning HTML file that expressed the intended experience directly.

Fortress then connected that front end to its internal back-end systems.

The prototype was the specification. The handoff preserved the design by giving engineering working code instead of interpretation.

The final front end reflected the decisions made during the executive workshop and was prepared for internal integration.

Detailed interaction and interface states were encoded directly into the working HTML handoff.

Design and Engineering Met in the Same Artifact

The project did not end with a presentation or visual specification. The deliverable was a working front-end implementation that the internal Fortress team could connect to its own systems.

That approach reduced ambiguity at the most fragile point in the process. The spacing, structure, visual hierarchy, and interaction intent were already present in the artifact engineering received.

It also demonstrated a working model for executive collaboration: align quickly in the room, translate decisions into a coherent product, then hand off something concrete enough to move directly into production.

The Fastest Path to Clarity Was Working Together, Then Building It

The strength of the project came from the sequence. The leadership team aligned together in the room. I took responsibility for translating that alignment into a coherent interface. Engineering received a working front end instead of a loose interpretation of the design.

For internal tools, that kind of continuity matters. Employees do not care how many systems sit behind the experience. They care whether the tool helps them complete the task quickly and with confidence.

The Fortress dashboard turned a complex set of internal IT workflows into a cleaner operational layer, and it moved from whiteboard to working browser experience without losing the decisions made along the way.