Knowledge Portal & Workspace

A stalled design direction reset to an aligned, defensible architecture in under a month, by refusing both of the options the customer had on the table.

A global technology manufacturer's field deployment organization needed a purpose-built knowledge portal for deployment resources, and was trying to force the use case into an existing enterprise employee portal that was already in place and politically favored. Field engineers, knowledge managers, and authors had overlapping but genuinely different needs. Licensing and the timeline ruled out the field service architecture that would have been the right long-term answer.

MY ROLE

UX Advisory Lead

TIMELINE

3 weeks, 4 workshops

SCOPE

Design direction already not working

I said no to both of their options and defended a third

The customer arrived with two candidate answers and both were wrong. Forcing the use case into the existing employee portal would have produced a customization with nowhere to go. Waiting for the field service architecture was not available inside the licensing and timeline constraints. I recommended an intermediate path instead: a focused knowledge base portal paired with a knowledge workspace, sized to the immediate need and explicitly documented as a step toward the field service vision rather than a substitute for it. Most of the value of the engagement was in refusing the two obvious paths and being able to defend the third.

Five personas were three experience types

The five personas the customer arrived with described job titles, and job titles were not what differentiated the experiences. Consuming knowledge in the field, creating and maintaining it, and governing it are three different relationships to the same content, and several of the five sat inside one of them. Collapsing to three is what made the architecture coherent. It cut the surface from five requirement sets to three, and exposed that the real tension was between the field consumer and the author, not between departments.

Taxonomy organized by task, not by owner

Field engineers were the primary audience and the least represented in the room, and they arrive with a job in front of them rather than a content category in mind. I restructured the taxonomy around what someone was trying to do, treating technical bulletins as their own class because their urgency and lifecycle differ from reference material. AI-assisted authoring entered as one component inside that structure, aimed at the author's maintenance burden, rather than as the premise of the portal.

What I'd revisit

I documented the path toward the longer-term architecture as a narrative rather than as a decision record with triggers. A future team inherits the reasoning without knowing what conditions should cause them to move. I would now write the "later" half as conditions rather than as a vision, so the handoff tells someone when to act and not just what I was thinking.