The team could say what was wrong with the homepage draft. Not what would be right. How do you brief a vendor on that?

Context

UCAN is the Ministry of Education's national career-competency assessment platform, administered annually to incoming students across Taiwan's higher-education institutions. By the time I joined ITRI's Talent Program team, its front end had gone roughly a decade without a visual refresh: an aging ASP system serving a national platform with a look that hadn't moved since it launched.

The UCAN team was four people, but this project belonged to just two of us: a full-time program manager and me. We were mid-negotiation with the design vendor, still at the "agree on an overall visual direction" stage, when the PM left for a new role. I was the only other person on the team with any hands-on web development background, so the project became mine by default, not by assignment.

That fact mattered more than my job title did. I wasn't just managing a redesign; I was the only person in the room who could translate between what the internal team wanted, what a vendor could build, and what our decade-old backend could actually serve.

The question

The main question wasn't "what should the new site look like" (everyone had opinions about that). It was: how do you get an accurate direction to a vendor when nobody on the team, including the person leading the project, can put it into words?

Sub-questions:

1. Is this actually a communication problem, or a translation problem: internal preferences that exist as taste but haven't been converted into something a vendor can build against?
2. Can whatever direction we land on actually be built on our existing ASP database, or are we about to promise a level of detail the backend can't serve?
3. Government sites carry a mandatory accessibility bar (WCAG AA certification). Does hitting that bar constrain the "modernize" goal, or is it a separate track entirely?

What would change the decision: if a cheap, fast artifact could resolve internal disagreement before it reached the vendor, the remaining ~15 page templates could all run on the same rhythm. If it couldn't, we were looking at a slower, meeting-by-meeting requirements process for every page, with real risk to the one-year timeline the Ministry expected.

Data

• Scope: a front-end redesign of a national assessment platform: at least 15 distinct page templates (informational pages, the assessment-taking flow, report-viewing), plus a lighter, visual-alignment-only pass on the back-end management console, with deeper back-end UX work deliberately deferred to a later phase.
• Vendors and stakeholders: three external vendors (platform maintenance, web design, content/illustration), ITRI's internal UCAN team, and the Ministry of Education as the funding and approving body.
• Timeline: about one year from internal requirements-gathering to launch.
• Comparison point: the homepage: 3 internal meetings reacting to the vendor's draft before I built a wireframe, versus at most 3 vendor revision rounds per page for every template that followed.
• Known limits:
  • The "3 meetings, then ≤3 rounds per page" comparison is what I remember, not something logged in a ticketing system at the time. There's no time-stamped record to point to. 🟡
  • There's no user-facing measurement here of whether students actually found the redesigned site easier to use. Everything below is measured in internal and vendor-process terms, not end-user outcomes.

Approach

Step 1: Name the actual problem before trying to solve it.

Three meetings in, the team had opinions about the vendor's draft (not quite this, not that either) but no shared, expressible picture of what they wanted instead. That's not a communication failure in the usual sense; everyone was communicating fine. It's a translation failure: preferences that live as taste, not as a spec anyone can hand to a designer.

Step 2: Build the missing artifact instead of scheduling another meeting.

I'm not a designer, and this wasn't a formal design process. I taught myself enough Figma to draw a wireframe of the homepage: rough colour direction, section layout, what to emphasize where, folded in each internal stakeholder's page-specific requests. It took about a day.

Step 3: Align internally before spending a single vendor revision cycle.

I brought the wireframe back to the team first. Getting to agreement on our own draft, before the vendor saw anything, meant the vendor wasn't absorbing the cost of our internal disagreement.

Step 4: Hand the vendor something to build from, not something to interpret.

Once the direction was set, the vendor implemented straight from the wireframe into an HTML-and-image mockup. The revisions that came back were component-level (spacing, a button style), not "let's rethink the layout."

Step 5: Repeat the pattern once it's proven, not before.

The homepage carried the most risk: highest information density, the site's first impression. That made it the right place to test whether a wireframe-first process actually worked before betting the rest of the project on it. Once it did, every remaining page template followed the same shape (team alignment first, vendor build second) and stayed within three rounds.

Running in parallel: reconciling the new design with a decade-old database.

Some of what the new pages wanted to show was more granular than the existing ASP database was structured to provide. Where that happened, the fix wasn't on the design side. It meant checking, page by page, whether the backend could actually serve the data shape the new design assumed, and adjusting the design where it couldn't.

Accessibility wasn't a fight. It was an integration task.

WCAG AA certification is a standing requirement for Taiwan government-affiliated sites, not something we negotiated. The design vendor built in the required components (skip-navigation anchors, font-size controls) by default. My work here was making those default components look like they belonged to the new design, not defending the new design against them.

What I considered and rejected: the annual reporting side.

The parallel track was replacing the outsourced statistical workflow behind UCAN's annual report to the Ministry. I tried Excel-based tools and macros first; the data volume was large enough that it regularly crashed the machine I was working on. We also had no internal SPSS license, which ruled out simply bringing the old tool in-house. Python and pandas were the only realistic option left, not the first one I reached for. I hosted the working notebook on Google Colab specifically, a deliberate choice, so that neither I nor the interns who'd inherit it after I left would need to manage a local environment to run it.

Findings

The clearest before/after is the homepage. Three meetings of reacting to the vendor's own draft produced no agreed direction. One day spent building a wireframe, followed by internal alignment, produced a vendor handoff that needed only component-level fixes. 🟡 (the "3 meetings → ≤3 rounds thereafter" comparison is recalled, not logged)

That pattern held for the rest of the front-end scope: roughly 15 page templates redesigned, delivered on the schedule the Ministry expected, with the AA accessibility certification passed.

The project also held to a boundary that made all of the above possible: this phase was scoped to front-end only, with the back-end limited to a visual-alignment pass and deeper back-end UX work explicitly deferred to a later phase. That wasn't scope creep avoided by luck. It was a decision made at project setup, and it's a large part of why "on time" and "on quality" were both achievable at all.

On the reporting side: the Excel/SPSS dead end is gone entirely, replaced by a Python/pandas pipeline that runs independent of any licensed software, hosted somewhere the next intern can open and run without an install step.

Recommendation

Build the shared visual reference before writing the vendor brief, not after the contract is signed. A moodboard with annotated "what we like about this, specifically" pulled from a handful of reference sites would have let us test feasibility and collect the vendor's own UX input during scoping, instead of discovering all of that three meetings into execution.

Separate what can be specified in words from what can only be specified by showing a picture. Route the second kind through a fast, cheap artifact one person can build in a day, not more rounds of verbal feedback on someone else's draft.

How I'd measure it: rounds of vendor revision needed per page, or time from kickoff to internal sign-off on direction. Both are something I only reconstructed afterward here; on the next project, I'd track them from day one.

Key learning

Scope precision at the start compounds. It doesn't just save time, it changes what's achievable later. The single biggest lesson from this project is that the moodboard should have existed before we talked to a vendor, not after. Every hour spent turning taste into something specific before contact with an outside party bought back multiple hours later.

With many vendors, the actual bottleneck isn't the work. It's making sure each party delivers on time without the follow-up feeling like debt collection. Coordinating three external vendors plus internal stakeholders meant I spent more time scheduling and tracking than analyzing. Learning to chase a deliverable without souring a relationship I'd need again the next week turned out to be its own skill.

And the classic project-management triangle (on time, on quality, on budget) stopped being a slide from a lecture and became the thing I was balancing, page by page. We didn't hit all three by accident. We hit them because we drew the scope boundary (front-end this phase, back-end next) before we started, not while explaining a miss afterward.