88 ways to ask for help, and no way to find the right one
Methods & deliverables
- Heuristic evaluation
- Card sorting
- Content analysis
- Information architecture
- Semantic taxonomy
- ServiceNow platform
- Accessibility considerations
- Design system evolution
- Engineering collaboration
- Governance framework
Context
A major Italian energy utility had an internal ICT support portal used by nearly 4,000 employees. The portal ran on ServiceNow, so the redesign had to work inside an established enterprise SaaS platform rather than a blank-slate product. Over the years, every team had added its own services, named the way that team understood them internally. By the time I joined, the directory had grown to 88 entries with no shared logic behind them, just years of departments solving their own problems in isolation.
Why this mattered
This wasn't a cosmetic problem. People couldn't find the right service, so they raised the wrong ticket, or gave up and called someone directly. And the friction didn't stop once a ticket was open. Status and next steps were often unclear, leaving people unsure whether something was waiting on them or simply in progress. On a system used by thousands of employees every day, that adds up to a real operational cost, not just a frustrating interface.
Constraints
Card sorting was run with real users of the portal, but not as a fully blind study. Some participants had been involved in the project from earlier phases and had already seen the results of the heuristic evaluation. Their input may have been shaped by that prior exposure rather than a fresh, independent read of the terminology. Alongside that, my team went through roughly 90 pages of real support requests, reading how people described their own problems in their own words, to widen the picture beyond that sample.
What I discovered
A heuristic evaluation against Nielsen's ten principles surfaced dozens of specific issues. Underneath them, four patterns kept repeating across the whole portal: inconsistent components and interactions, weak feedback on system state, terminology built around internal IT structure instead of user mental models, and critical moments left unprotected where a mistake was costliest.
The weak feedback pattern showed up most clearly after a ticket was opened. Status changes and next actions weren't communicated in a way that told people whether the ball was in their court or someone else's, so they'd default to calling to find out. The terminology pattern showed up earlier in the journey: menu labels routinely pointed to destinations that didn't match what they promised, evidence that the whole portal had been built from the inside out, department logic first, user logic never.
The whole portal had been built from the inside out. Department logic first, user logic never.
Two of these patterns pointed at the same root cause. People weren't just struggling with individual screens, they were navigating a system organised around IT's internal logic instead of their own. That's what turned this from an interface fix into a structural one. Relabelling a few menus wouldn't help if the underlying organisation of services still didn't match how people actually thought about their problems.
Key decisions
The clearest decision was shifting from supply-side logic to demand-side logic, naming things the way people ask for them rather than the way IT organises them internally. Getting there took testing three ways to group the directory: by object, by action, and by service type. None of them held up alone, because different users think about the same problem differently. An engineer searching for a broken tool types the name of the software. An intern with the same problem types "malfunction." Neither is wrong, and a single taxonomy would have made one of them invisible to the system.
So instead of forcing one logic, we merged them. Each entry under the five macro-categories carries object, action, and type together, so it's findable however someone happens to be thinking about it that day. The multi-tagging also strengthened the search layer, allowing AI-assisted retrieval to match the same service from different types of queries.
Trade-offs
The card sorting gave us genuine input from real users, which mattered. But some participants had prior exposure to the project and its findings, so the results likely carry some bias toward what they already expected to see rather than a fully independent read. It's a limitation I'd flag rather than hide. The sample was real, but not clean.
Solution
We kept one thing deliberately unchanged. Some users, mostly managers approving routine requests or people opening the same kind of ticket daily, already had a flow memorised and didn't want or need the new guided experience. For them, the ticket flow preserves something close to the old, direct path, so the redesign didn't slow down the people who were already fast. Alongside that, we added the ability to save not just drafts but full templates, plus favourites, for anyone who opens the same type of request repeatedly. It meant building two experiences that felt like one system, not compromising the new structure to protect the old habits, and not forcing habitual users through a guided flow they didn't need.
The rebuilt directory went from 88 entries to 34, organised around five user-centred categories with the merged tagging system underneath. Full-application wireframes covered every flow, from the homepage and directory to request forms, appointment booking, and the manager approval queue, treated as one connected system rather than isolated screens. This became an interactive prototype across desktop and mobile, tested with stakeholders before development.
The heuristic findings also informed work on the design system. Rather than treating recurring interface issues as isolated screen fixes, we used them to guide a more consistent approach to components and interactions. Accessibility considerations were included in that work, without framing the project as a formal accessibility audit or claiming full compliance.
The wider design-system initiative later explored AI-supported workflows between design documentation and implementation. This was an engineering-led proof of concept on a controlled portion of the system, with human review kept central. My contribution was limited to the design side and readiness for handoff; the technical implementation remained with engineering.
The last piece was a governance framework, a scoring model across five dimensions that decides whether a new service belongs fully in the directory, links externally, or stays separate. It was tested against real past cases before release, and it gave the right answer on both, with a clear reason attached. That was the part meant to outlast the project. Without it, the directory would start accumulating the same way it did the first time.
Impact
The merged taxonomy was designed to support different ways of searching, including assisted retrieval. The governance framework gave the team a repeatable way to evaluate future services instead of adding them without a shared rationale.
My role
I led this project end to end. I managed the client relationship throughout, ran the workshops and stakeholder conversations, and made the calls on scope, priorities, and sequencing. I guided the design team's work and collaborated closely with engineering around ServiceNow constraints and implementation handoff, keeping decisions grounded in what was buildable, reusable, and governable within the timeline and budget we had. I also had a small supporting role on the later AI-supported proof of concept, focused on the design-system side of the handoff.
What I'd do differently
If I could rewrite the brief, I'd want a cleaner, more independent sample for card sorting from the start. That part wasn't fully in my hands. The engagement was scoped around internal stakeholders already close to the project, and widening that pool wasn't a decision I could make alone.