Cadence
Rework a team’s ignored portal around a new way of working — and leave behind a blueprint the company could repeat.
Cadence’s QA team had an internal portal that was cumbersome and mostly ignored. As UX consultant I led the pilot that reworked it around community and file sharing — and, just as importantly, produced a repeatable design and migration blueprint the rest of the company could follow.
The team had a portal. Almost no one used it.
When I came on, the QA team already had an internal portal — the problem was that almost nobody used it. It was cumbersome and mostly outdated, so the broader team had never really adopted it: too complex to be worth the effort. A place meant for collaboration had quietly become a place people worked around.
Hard to navigate, harder to contribute.
Content no one trusted or maintained.
A version upgrade wouldn’t fix adoption.
IT wanted to move the whole company onto a better setup, and the temptation was to treat this as a version upgrade — lift the content, drop it somewhere new. But moving a cumbersome site somewhere new just relocates the problem. Adoption is about how people work — not where the files live.
Lift the files, call it done.
Drop them on a newer setup — and inherit the same low adoption.
Rebuild around how the team collaborates.
So people want to live in it — and it works for QA and scales to every other team.
And the company was far too big to prove that everywhere at once.
Two outcomes, one pilot.
So the team ran a pilot: pick one content-heavy, well-defined group — QA — rework their portal end to end, and come out with two things at once.
A portal they live in
QA’s site reworked around community and file sharing, so finding and sharing work is easier — not just relocated.
A repeatable blueprint
A design and migration approach that hands cleanly to the next team, and the next after that.
Two principles held it together → every choice had to be scalable, and the new site had to be genuinely easier than the old one.
Two beliefs to make true.
We framed the work around two beliefs — and the design’s whole job was to make both of them true.
Adoption rises if it’s built around how people work.
Communities, discussions, shared files — not a faithful replica of the old tangle.
Prove it with one team, and it justifies the whole company.
One content-heavy team is enough to earn the company-wide rollout.
“We understand this well enough to build it.”
The biggest assumption baked in at the start was that we understood this new way of working well enough to build it. I was skeptical — I was living the gap firsthand. So instead of papering over it, we closed it: the team found room in the budget to bring on two Microsoft consultants, to work alongside us.
Truly understand the platform’s capabilities.
Make sure everything we built would scale across the entire company.
Content and current-functionality audit.
My hands-on work was the UX spine, and it started with an audit — three moves to find out what the site really was before deciding what it should become.
Two card sorts rebuilt the structure.
With the audit done, I moved into information architecture — deciding how QA’s content should be grouped and named, instead of replicating the tangle that had failed to catch on. I ran both an open and a closed card sort with the team.
Let the team group and name content themselves.
Surfacing the real mental model, not the one the old site had imposed.
Checked content against the proposed groupings.
Validating the categories held up under real content.
The result → a grouping-and-naming backbone the site — and the rollout — could be built on.
Two screens carried the whole argument.
Working with the platform’s existing modules plus some customizations — and handing the build to the Microsoft consultants — the design converged on two core screens. The ones that carried the argument for the whole migration. Everything else is a refinement of these two.
Community portal homepage
Featured communities up top; a What’s Hot / Recent toggle; each tile carrying its own member and discussion counts, so the space feels alive rather than archival.
Discussion overview page
A highlighted best reply, up/down voting on responses, a Top Contributors rail, and sort controls — so a busy thread stays navigable.
Wireframe first. Then a production SharePoint skin.
Each screen shown twice: the low-fidelity wireframe that proved the structure, and the same screen taken to a production skin built in the SharePoint Web UI Kit — the platform’s real visual language, with the site header, hub nav, command bar, and web parts.
Structure first: a row of featured communities up top, a What’s Hot / Recent Communities toggle over a grid of community tiles, each showing member and discussion counts — the whole layout signalling activity so the portal reads as a living place. The production skin dresses that same structure in the platform’s real visual language: site header and hub navigation, a command bar, featured community web parts, and a What’s Hot pivot over live cards with a face-pile of members.
Modelled loosely on the Stack Overflow pattern: a question at the top, a highlighted best reply, up/down voting on every response, sort controls, and a right rail carrying the post’s stats and its top contributors — so a long thread stays navigable. In production, that pattern renders as a real SharePoint page, the accepted best reply called out in green. This is the screen that made community feel worth showing up for.
Every choice had to scale.
The hardest constraint wasn’t any single screen — it was that every decision had to be scalable. A design that worked beautifully for QA but couldn’t be carried across every other team would have failed the actual goal. That constraint sat behind every layout and content choice.
Great for QA. Impossible to repeat. — the failure mode we designed against. The KPI wasn’t a vanity metric; it was that the pilot be delivered in a way that was scalable across the entire company.
Split cleanly along expertise.
Implementation split cleanly along expertise — then converged.
Offloaded the pilot content onto the new server.
All the content tagged for the pilot, moved off the current installation.
Built the site infrastructure off the card sorts.
The open and closed sorts became the structure directly.
Then, as a team, we populated the content and converged on one consistent design concept that could carry across the entire rollout.
It launched as my engagement wrapped.
I’ll be honest about the ending. The QA quality portal went live on the new setup — right before I rolled off the engagement. So I saw it ship and the migration approach take shape, but I left before the longer-term adoption and rollout numbers came in, and I won’t claim results I didn’t see. What I can say is that the pilot did the two jobs it was scoped to do.
A live portal
A community-driven quality portal QA could actually work in.
A repeatable blueprint
A design + migration approach ready for the broader rollout.
Structure and process, over any one screen.
The card sorts and content audit did the heavy lifting.
They were the difference between a site QA would adopt and one they’d quietly ignore.
The deliverable wasn’t one good screen.
It was a process solid enough for other teams to repeat without me in the room.
An ignored intranet, reworked into a portal a team lives in — and a blueprint the whole company can follow.
The lesson that outlasts the project: adoption isn’t about where the files live — it’s about designing the way people work together, and making that repeatable.
Honest framing: I rolled off as the pilot launched, so no adoption or rollout figures were captured and I don’t quote any — the outcome was a live site and a repeatable blueprint.