Skip to content
Masthead stand instack

Framing

The service could describe every fund it ran and could not say who any of them were for.

Where the work started

A funding site that answered the wrong question first.

The team arrived with a redesign already scoped. The site was slow, the pages ran long, and nobody liked the search results. Every one of those things was true, and none of them explained why the support line kept taking the same call twice a week.

So the first fortnight went on that call instead. Applicants were not lost in the interface. They were stuck a step earlier, unsure whether the programme in front of them was meant for a business their size, in their state, at their stage.

Research

Twelve conversations in, the problem was not the rules. It was not knowing whether the rules applied to you.

What we heard

Twelve interviews across four states, weighted toward people applying for the first time.

We recruited for recency rather than success: anyone who had looked at a grant in the last six months, whether or not they went on to apply. That skewed the sample toward the people the site was losing, which was the point.

The sessions ran for forty minutes with the live site open. We asked people to find something they might be eligible for, then to say out loud how confident they felt about that answer. Confidence turned out to be the useful measure. Most people could find a plausible programme. Almost nobody trusted their own reading of it.

The same four moments came up in nearly every session, and they were all moments of doubt rather than moments of difficulty.

  • Reading the eligibility list and finding no example that resembled their business.
  • Hitting a term of art with no plain definition anywhere on the page.
  • Finding two programmes that looked identical and no way to tell them apart.
  • Reaching the closing date and not knowing whether late meant late or meant next round.

How we sorted it

Every quote went onto one wall and got clustered by what the person was trying to settle, not by which page they were on. Six clusters held. Four of them were versions of the same question, which is how we knew the navigation was not the thing to fix first.

The team pushed back on this, reasonably. A structural finding is expensive and the redesign was already funded. We agreed to test the cheap version of the structural answer before anyone committed to the expensive one.

Information architecture

The structure was a filing cabinet. People arrived with a situation, not a category.

Reading the current structure

The existing site was organised by the department that owned each programme. That is a real structure and it is the correct one for the people who run the funds. It is useless to someone who has never met the department and does not know that a fund exists to be found.

Mapping it end to end took a week and produced a diagram nobody could read in one sitting. That was the finding: eleven top level entries, four of which were named after internal teams, and two paths to the same application form depending on which entry you came through.

The flow we proposed

One entry, a short set of questions, and a shortlist you can act on.

The proposal inverts the structure. Instead of asking people to pick a category, the flow asks about the situation they are already in, then does the matching itself. Nothing about the underlying programmes changes. What changes is who carries the burden of knowing how they are filed.

The questions are the whole design problem. Too few and the shortlist is no better than a search result. Too many and the flow becomes an application form before anyone has decided to apply. We landed on five, with a visible count so the end is always in sight, and every one of them answerable without looking anything up.

The exit is as important as the entry. Someone who answers the questions and matches nothing must leave with something other than an empty page, so the no result state routes to the two programmes with the broadest criteria and says plainly why they were shown.

Arrive from a search result or a referral
Describe the business in one line
Answer five situation questions
See the shortlist, each card carrying its match reason
Correct an earlier answer without losing the list
Open one programme and read the full criteria
Save the shortlist or start the application

The plate above is deliberately the tallest thing in this fixture. It stands in for the real flow diagram, which cannot be shrunk to fit a viewport and stays legible, and it is the section that behaves differently under all three scroll options.

Note what happens when you reach it: how the previous section leaves, whether the page fights the length, and whether the section after it recovers cleanly or arrives in the wrong place.

Testing

Five sessions were enough to kill two ideas and rescue a third.

Five sessions

A clickable prototype, moderated, with the same task everyone had failed on the live site.

We built the flow as a prototype with real programme copy rather than placeholder text, because the doubt we were designing against comes from wording. A prototype in dummy copy would have tested the layout and missed the problem entirely.

The first two sessions went badly in a useful way. Both participants answered the situation questions confidently and then stalled on the shortlist, because the cards showed the programme name and the funding amount and nothing about why it had been matched. Without the reason, the shortlist read as another search result.

We added a single line to each card naming the answer that produced the match. The next three participants read that line first, every time, and two of them used it to go back and correct an earlier answer. That correction loop was not designed. It appeared because the reason was visible.

The second thing we killed was a progress bar. It tested as pressure rather than reassurance, and it competed with the question count for the same job. Removing it made the flow feel shorter, which is the opposite of what the team expected.

The third idea, the one that survived, was the plain language definition shown inline the first time a term of art appears. Nobody praised it and nobody mentioned it, which for that kind of element is the result you want.

What we could not test in five sessions was the return visit. Everything here is about a first pass through the flow, and the behaviour of someone coming back a fortnight later with half an application saved is an open question the team took into the build.

What changed

Three changes went into the build off the back of the sessions: the match reason on every card, the inline definitions, and a shortlist that keeps its order when you go back and edit an answer.

The order point sounds small and was the most argued over. Keeping the order stable means the shortlist is sometimes not ranked best first after an edit. We took that trade because a list that reshuffles under you destroys the thing the reason line just built.

Outcome

People stopped asking whether they were eligible and started asking what to prepare.

Where it landed

The flow shipped as the primary entry to the funding section, with the old category navigation kept in place beneath it for the people who already know what they are looking for. Both routes reach the same programme pages.

The support line still takes the eligibility call. It takes it later in the process now, and the question has changed shape: less whether this is for me, more what counts as evidence. That is a better question to be asked and a cheaper one to answer.

PinStack