12 Nov Choosing What to Build First: Judging Ideas by Impact and Feasibility
Part 9 of Start the UX Design Process — a series on the UX principles I use in client work.
Ideation gives you a pile of ideas. That pile is a problem of its own, because you cannot build all of them — and if you try, you will build all of them badly. Every website project eventually faces the same question: with limited time and budget, what do we build first?
The honest answer is not “the best idea.” It is “the idea that helps the most people the most, for the least cost, soonest.” That sentence hides two judgments, and learning to make them cleanly is what separates a focused redesign from a bloated one.
Judgment one: impact
Impact means: how much does this idea help the primary persona finish their job, at the journey step that matters most? Not how impressive it looks. Not how much the team likes it. How much it moves the problem statement from the seventh post.
A “happening now” view for day-of festival attendees has high impact, because it serves the primary persona at the moment of truth, on a phone, in a hurry. A homepage slider has low impact, because it serves nobody’s job — visitors scroll past it to the schedule anyway. A shorter donate form with a clear explanation of what a gift does has high impact, because it removes hesitation at the exact step where donors stall. A new photo gallery has low impact if the visitors’ real problem was finding service times, no matter how beautiful the photos are.
Impact is judged against the research, not against taste. Go back to the problem statement, the hypothesis statement, and the goal statement from the last two posts: does this idea fix the broken step, and does it deliver the outcome the hypothesis predicted, in the way the goal statement measures? Ideas that fix broken steps are high impact. Ideas that polish working steps are low impact, however pretty they are. The competitive audit from the last post belongs in this judgment too: an idea your competitors already do well is less distinctive than one that fills a gap they all leave open, which is the value-proposition test from post seven applied to a single feature.
Judgment two: feasibility
Feasibility means: how hard is this to build well, with the time, tools, and people actually available? Not “can it be built in theory” — almost anything can — but “can it be built well, maintained, and kept working by this business, with this budget, on this platform?”
A plain-text schedule that loads fast on a weak signal is highly feasible: simple to build, easy to update, hard to break. A custom interactive map with live updates is less feasible for a small team: it needs data nobody has time to maintain, and the week it goes stale it becomes a liability. A shorter form is highly feasible. A whole new registration system is not, unless the registration problem is truly the business’s biggest problem.
Feasibility also includes maintenance, which small businesses forget and then pay for. An idea that needs weekly updates from a volunteer who may leave is less feasible than it looks on launch day. An idea that the business owner can update in five minutes is more feasible than it looks, because it will still be accurate in six months.
Sorting the pile
Put the two judgments together and the pile sorts itself into four groups. High impact and highly feasible: build these first. They are the redesign’s core — the schedule that loads fast, the shorter form, the clear guest path. High impact but hard to build: plan these second, or find a simpler version that captures most of the impact for a fraction of the effort. Often there is one: a simple filter instead of a custom app, a clear story page instead of a whole campaign microsite.
Low impact and highly feasible: these are tempting, because they are easy wins that feel like progress. Resist them, or at least put them last. A site full of easy, low-impact features looks busy and feels unfocused — the exact opposite of a site built around a visitor’s job. Low impact and hard to build: do not build these at all. Saying no to them is not a lack of ambition. It is the discipline that keeps the budget for the work that matters.
I sort ideas this way with clients in the open, on one page, because the conversation it creates is worth as much as the sort itself. A stakeholder who sees their favorite idea land in “low impact, hard to build” understands the decision in a way that “no” never conveys. And a client who sees their schedule fix land in “high impact, easy to build” understands why the redesign starts there, not with the homepage slider they originally asked for.
Sorting in practice: a festival example
Picture the pile of ideas after ideation on a festival site. A “happening now” view for day-of visitors: high impact, highly feasible — it is mostly a rearrangement of schedule information the event already publishes, presented for phones first. Build it first. A custom interactive map with live stage updates: high impact in theory, but hard to maintain for a small team, and it goes stale the moment a stage time changes and nobody updates it — plan it second, or build a simpler version, like a clear static map with parking marked, that captures most of the value.
A photo gallery of past festivals: easy to build, low impact for the visitor trying to find today’s schedule — put it last, not first, however much the team enjoys looking at the photos. A whole new ticketing system: low impact if the real problem was finding information, and hard to build — do not build it at all on the strength of this project. Laid out that way, the sort almost makes itself, and the client can see why the redesign starts with the schedule, not with the gallery they originally asked for.
The first build is a test, not a verdict
Choosing what to build first is not choosing what to build forever. The first build goes live, real visitors use it, and you learn — which is the next phase of the process beyond this series, prototyping and testing. An idea that looked high-impact but underperforms gets revised. An idea that was parked as “later” gets promoted if the research supports it. The sort is a starting order, not a life sentence.
That is the whole arc of this series in miniature: listen first, name the problem, generate widely, choose wisely. Empathize, define, ideate — not as a ceremony, but as a way of spending the cheap effort up front so the expensive effort, the build, lands on the right thing.
The final post in this series is personal: what this way of working actually changed in my own process, on real client sites, and why I keep coming back to it even after years of building websites.
Want help deciding what your site should build first? I build and redesign websites for small businesses, non-profits, and churches across Eastern NC. Get a free consultation or see recent work.
Previous in this series: Ideation · Next: What Course 2 Changed in My Work
This article is my own take, in my own words, on UX principles I use in client work. It is not affiliated with or endorsed by Google or Coursera.