Igloo Software · Digital Workplace Content Architecture
Ambiguity to Architecture
Defining, scoping, and shipping Igloo's first wiki system.
User impact: Wikis and articles share one content model, so cross-linking, search, and discovery behave consistently no matter which content type someone's in.
Biz impact: Shipped as a reusable content pattern other Igloo content types were built on afterward, instead of a one-off system requiring separate long-term maintenance.
The Problem
Starting From Ambiguity
I joined this epic in my first month, into a project that had already stalled on a deceptively simple question: what is a wiki, and how is it different from a blog, an article, or a feed? The team had been circling this for weeks without resolution: different people used “wiki,” “article,” and “blog” interchangeably in the same sentence, which meant design, product, and engineering were often solving three different problems while thinking they agreed. By week four, I was effectively co-leading the epic alongside my UX manager, not because I was assigned to, but because someone needed to convert that confusion into a framework the team could actually build against.
Framing Before Designing
Defining the Difference That Actually Mattered
Rather than start sketching screens, I worked with my UX manager to build the information architecture from first principles, mapping how a user would move from a company-wide wiki homepage down through nested topic areas to an individual article, the way volumes of an encyclopedia nest under a shared set. We pulled reference patterns from Wikipedia and Notion, not to copy them, but to understand why their navigation worked the way it did.
The distinction that came out of that work was the one that actually mattered: blogs are moment-in-time; wikis are evergreen. A blog post is a piece of content that flows past. A wiki article is meant to be cross-linked into a growing web of related knowledge, the way a Wikipedia reader can click from one article to an adjacent one indefinitely, discovering context along the way. That reframing did two things at once: it gave the team a functional reason for wikis to exist as their own content type, and it let us simplify the terminology, since “wiki article” collapsed down to just “article,” because once you're inside a wiki, the label stops doing useful work.
Holding the Line on Architecture
Refusing to Let the Data Model Get Decided Before the Problem Was
Once engineering joined the conversation, the fastest path forward, the one that kept surfacing, was to treat wikis as a special case bolted onto the existing article model with a feature flag. It would have shipped faster. It also would have meant maintaining two parallel content systems long-term, without ever having actually defined what made them different in the first place.
I stopped that conversation before it became a decision.
“I'm not yet clear on what I've been hearing so far. Is it you can't do this, you can't do that? I want to understand what's working and what's not working before we push something forward.”
My manager backed the position explicitly in the room. The resolution we landed on instead, a shared base content class with configurable features per content type rather than two isolated systems, became the actual technical foundation the team built on, and it's the kind of trade-off that's easy to skip under deadline pressure and expensive to unwind later.
The Reframe
Naming What the Design Actually Was
Midway through design review, I identified something the team had been building around without saying out loud: the “wiki feed” page, as designed, wasn't functioning as a landing page or a homepage. It was functioning as a search-results page, more like a hashtag feed on social media than a place someone would land intentionally. Getting the team to agree on that (my manager's response: “point blank, that's exactly it”) reframed what we were actually designing and separated two problems that had been tangled together: how do people discover a topic, versus how do people browse everything tagged with it.
When my manager later challenged the landing page directly, asking why it was needed at all, I had the answer ready because of that earlier framing work: without it, users land straight on an article with no sense of where they are in the hierarchy, which was the exact disorientation problem the epic existed to solve. Holding that position under direct challenge, rather than deferring to seniority, is what kept the hierarchy intact in the final design.
The Scoping Save
Turning an Unscoped Ask Into a Buildable MVP
The moment I'd point to as the clearest example of judgment in this project: I was asked to deliver a “high-fidelity” wiki feed page, but the ask, on inspection, actually bundled together four or five distinct, unscoped flows: search, filtering, an index/table of contents, and article creation, each of which was its own design problem. Building all of it as asked, on the timeline given, would have meant working overnight to produce something that still wouldn't hold up to real engineering questions.
Instead, I initiated a working session with my PM and manager and asked the question that unlocked it: is this asking for high-fidelity visuals, or the actual flow for how one of these pages gets created? That distinction mattered. It turned a vague, oversized request into a scoped conversation. What came out of it was a real MVP: a title, a simple alphabetized index, bare-bones keyword search, and a CTA into the existing article-creation flow, with filtering, hero imagery, and “popular topics” explicitly deferred and labeled as future work rather than quietly dropped.
“I could do what you're asking, but it feels like it would be lacking substance.”
I didn't get there without friction, and I think that's worth being honest about rather than polishing out: partway through the scoping conversation, I pushed back on how thin the resulting design felt. I wasn't overruled; I was talked through the reasoning, and the MVP framing held up. But naming that discomfort instead of quietly complying is part of why the final scope was defensible rather than arbitrary, and it's a habit I've kept: flag the trade-off out loud, then commit once the reasoning holds.
In the Room With Engineering
Presenting the System, Not Just the Screens
In pre-planning, I presented the design to the engineering team using an atomic design breakdown: title, index, and search bar as atoms; a hero component as a molecule; the full page as the assembled organism. This gave engineers reusable building blocks instead of a one-off page to implement once and discard. I fielded real-time technical questions live: duplicate entry points for content creation, how cross-linking should behave, how the index would populate from a feed's contents. That's a different skill than producing the designs themselves. It is translating intent into something a front-end engineer can actually estimate against, in the room, under questions.
That same instinct for protecting scope showed up from the other direction too: when search-with-filtering was proposed for a feature nobody had evidence users needed, my manager articulated the standard we'd been holding to all along, “value comes from solving problems… I'm not convinced there's a problem,” and the team cut it rather than build speculative complexity. Scoping discipline ran in both directions on this project: toward more when the substance was missing, toward less when the need wasn't proven.
Outcome
“This is so much better than week one, where we were essentially trying to jam classic into React.”
What Shipped, and What Outlasted the Epic
The wiki content type shipped as a subclass of the existing article model, validating the architecture decision from earlier, with the index component built as a reusable pattern rather than a one-off, later becoming a template for how other content types would be built.
That's the throughline I'd want a hiring panel to take from this: the design decisions mattered, but the repeated discipline of stopping to ask what are we actually solving, even when it meant slowing down, disagreeing with a manager, or admitting discomfort with a scoping call, is what made the shipped product hold up.
Looking back, the arc of this project was an extended onboarding into the product, disguised as a design epic. Most of the value came from building shared understanding before building screens.