You can have a strong deck and clever technology and still not know if the idea itself is worth building.
Most founders know they should validate first. Very few know what that actually looks like when you involve digital product design and web design. Do you need a full brand. A polished app. A long survey. A research report.
From what we see at Webgamma, the answer is usually simpler. You need a clear problem, a specific user, a basic story that lives on a real page online, and a small product experience that people can react to with their mouse and their calendar, not only with nice words.
In this guide we walk through how we help pre seed and seed teams validate ideas using simple landing pages and clickable prototypes, mostly in SaaS, but the same logic works for similar B2B products.
This is not theory. It is the pattern we keep seeing across founders who arrive a bit past the napkin stage, and the pattern we wish some teams had followed before they spent six months on a full build and a shiny site.
Where Startups Really Are When They Reach A Design Team
Most teams do not show up with a blank page.
For SaaS, they usually arrive with a prototype and a handful of early users. There is something in Figma or a basic product live, a few customers testing it, maybe a bit of revenue. The problem is that the story, the product, and the website are not aligned with what is actually working in the field.
For climate tech, it is often the opposite. The technology and research are solid, pilots are starting or planned, there may be lab data and program reports, but there is almost no real product UX. Messaging is rough, and the website reads like a funding document instead of something a real operator can understand and trust.
Pure idea on paper tends to come through accelerators or referrals. In those cases we try to slow things down. Before we touch a full brand or complex site we push for real problem interviews and one or two lean experiments. Otherwise the whole design process becomes an expensive way to decorate guesses.
Validation through design has to start from where the company actually is, not from where the latest slide says it is.
When Teams Skip Validation And Go Straight To Build
We sometimes see teams decide that validation is for other people and jump straight into a full product build and glossy web presence.
One team with an employee wellbeing idea is hard to forget. They were sure every company would want their platform. They spent about half a year on a custom product build, a large branding project, and a polished marketing site. All of this happened before they had a single paying customer.
When they finally started selling, they ran into very basic questions. Who inside a company really owns this problem. Whose budget does this fall under. Is this an urgent issue or something that can wait until later.
HR contacts liked the idea when they saw the clean interfaces. When it came to signing anything, enthusiasm dropped. There was no clear owner and no real urgency.
The result was a lot of sunk cost. After launch they had to reposition the product, remove features, and simplify messaging. All of that could have been explored early with simple prototypes and one or two landing pages.
Validation will not remove all risk. Skipping validation multiplies risk and makes every later decision more expensive.
Step 1: Turn A Fuzzy Idea Into One User And One Moment
Many founders arrive with a wide statement such as “We want to fix operations for field teams.”
It sounds ambitious. It is almost impossible to validate in that form.
In one workshop we had a team with almost that exact line. Inside their own small group, everyone meant something different. For one person the idea was scheduling. For another it was a data collection tool. For a third it looked like a kind of operational CRM.
The first job of design in validation is not to pick colours. It is to reduce that fuzziness.
We map real use cases and ask direct questions. In which context does this happen. Who exactly is doing the work. At what moment in their day does the friction appear. What do they use today to patch the gap.
That exercise alone kills a lot of fantasy features. When every element has to connect to a real workflow, many nice ideas suddenly feel heavy. This team realised that scheduling had real pull. People were already hacking it with spreadsheets and chat apps. Other parts of the big platform pitch did not land when described in concrete terms.
Through a simple prototype and ten user conversations, they moved from “fixing operations for field teams” to a smaller idea in one vertical around one recurring workflow. The rest went to a later list.
Validation in that case did not kill the idea. It killed the vague version and left something grounded enough to test.
Step 2: Turn Assumptions Into Questions For A Short Sprint
Once the idea is narrowed to one user and one moment, assumptions become testable questions.
Instead of “Managers will love a better dashboard,” the question becomes “Are operations managers willing to change how they plan work if it saves them real time in this specific weekly task.”
Instead of “Utilities will want this analytics layer,” the question becomes “Will one utility or industrial partner commit time and data for a pilot in the coming months.”
We like to package these questions into a short validation sprint that lasts one to three weeks. There is a clear start and a clear end. It is not months of endless tweaking.
In the first days we talk to real people. This is not a broad survey. It is five to ten conversations where we mostly listen. We ask people to walk us through their current workflow, what is annoying, what they tried before, where they have simply accepted that “this is how it is.”
From those conversations we draft one clear value proposition and one simple story. At this stage the wording can feel plain. That is good. It needs to be specific more than clever.
Then we decide what to build to test that story in the real world. Usually that means one focused landing page and one clickable prototype of the core flow.
The important part is that before building anything we know what we will look for at the end of the sprint. Reaching the last day and saying “What do we feel like doing now” is exactly what we want to avoid.
Step 3: Use Landing Pages As Lean Experiments
At Webgamma we treat landing pages and small sites as cheap experiments, not as portfolio pieces.
A typical pattern is to build a one page site in a tool like Webflow or Framer. The page tells one focused story. One audience. One promise. One main call to action.
For a B2B idea, the call to action is usually something like “Request early access” or “Book a quick call.” We are not trying to collect a huge list of passive email addresses. We are looking for people who are willing to give time and context.
Then we send real traffic. Sometimes that is targeted outreach through the founders network. Other times it is a small paid test to a narrow audience.
What we learn here is not only the number of signups. We pay attention to who responds quickly and with substance. Who shows up to calls. Who brings colleagues. Who goes silent. That pattern says more than any large anonymous number.
For climate tech ideas, the same page can be used in a slightly different way. The team may share it directly with potential partners, grant reviewers, or program managers. The goal there is to see if they understand the story, whether they forward it internally, and whether it helps move conversations from “interesting research” to “possible deployment.”
The landing page is not the final brand. It is a tool to see how the market reacts when the story appears in public rather than staying inside a slide deck.
Step 4: Use Clickable Prototypes To Test Workflows
Words on a page are not enough. People can like the concept and still struggle with the way the product works.
Clickable prototypes help bridge that gap without a full build.
We use Figma to create short flows that simulate the core job to be done. Buttons react, screens change, and the content feels plausible. It is close enough to give people a realistic sense of how their day would change.
We then put this in front of a small number of real people, ideally the same type of people who reacted to the landing page.
During these sessions we watch more than we talk. We observe where people click, where they hesitate, which parts they ignore, and what they say out loud when they are confused.
We want answers to simple questions. Does this flow match their mental model. Does the order of steps make sense. Do labels and copy feel natural or do they sound like internal jargon.
The goal is not to collect praise for visual design. The goal is to see whether the idea holds up when someone tries to use it, even in a simplified form.
Step 5: Pair Landing Page And Prototype In One Flow
The most useful pattern is to combine both tools into one experience.
A simple version looks like this. Someone sees the landing page and feels the idea is relevant. They click the call to action and book a short call. During that call the founder or product lead walks them through the prototype.
Now we are learning on three levels at once.
First, whether the landing page attracts the right kind of person.
Second, whether they are engaged enough to give thirty minutes of their time.
Third, once they see and click through the flow, whether they still care. Whether they ask concrete questions. Whether they start imagining this in their own context.
We can also send the prototype link after the call. Then we see who opens it, who reaches the end of the flow, and who writes back with comments. That behaviour shows who is serious and who was just being polite.
This combination of story and experience is where validation through design starts to feel real. It is much closer to the way people will discover and use the product later.
Signals That An Idea Is Worth Pushing Further
For SaaS and B2B related products, the signals of a promising idea look a little different, but they share a simple principle. People put something tangible on the line.
For SaaS, strong signals include people booking calls or signing up without constant chasing, showing up prepared, engaging with the prototype, and being annoyed when access is limited or the product is taken away. Even a small group of such customers matters.
For climate tech, the signals are more about commitment and seriousness than raw signups. Letters of intent, pilot agreements, joint grant applications, strong interest from utilities or industrial operators, or acceptance into relevant programs. If a partner is willing to put the project into planning documents or public material, that has real weight.
Across both areas, we look for skin in the game. Time. Data. Budget. Reputation. A place in a process that matters.
If all that exists is positive comments and a list of vaguely interested emails, the idea is still in a warm but grey zone.
How Much Design Is Enough In Validation
There is a tricky balance in validation. The idea and the experience should look believable, but the team should not spend months on visuals before there is proof that the concept works.
On the brand side we aim for a minimal and coherent identity. One or two type families that read well, a simple colour palette, and a basic logo or wordmark that does not look like a placeholder. Enough for people to feel they are talking to a real company, not a side project that might vanish.
On the product side we focus design effort on one or two key flows, the ones tied directly to the value the team is promising. We make those flows feel real. States, buttons, content, and basic transitions receive care. Large component libraries and rare edge cases can wait.
The minimum quality bar is simple. Nothing should loudly signal “this is fake.” Testers should be able to spend their mental energy on the idea and the workflow, not on forgiving broken interface elements.
Someone who does not know the company should be able to imagine this becoming a real product in a few months without needing a big mental leap.
How Validation Fits Into Building A Successful Startup
Idea validation is only one part of the wider journey. It helps you avoid building the wrong thing, but it does not tell you how to hire, raise, or structure the product roadmap over the next years.
When we work with founders, we see that the strongest teams treat validation as an ongoing habit rather than a one time step. They use landing pages and simple prototypes to test new directions, but they also keep an eye on market timing, team strengths, and the long term story they are building in the background.
If you want to zoom out and look at the bigger picture beyond this first validation phase, it can be helpful to pair this article with a broader guide on how to build a successful startup. That kind of resource covers topics like choosing a model, shaping a roadmap, and planning funding, while this article stays focused on using design and landing pages to make sure the idea you are pushing actually deserves that level of commitment.
Narrowing Your Audience Based On Real Behaviour
One of the most valuable things validation does is force a team to decide who they really serve.
We saw this clearly with a B2B maintenance tool. The founder initially described it as “for any company with equipment.” That technically included a huge range of businesses. It also meant the story was vague and the examples were generic.
The first landing page used that wide framing. There were clicks and a few signups. When we looked closely at the conversations, the serious discussions all came from one type of company with multi site operations and a certain scale.
So we rebuilt the page around that group. The hero copy named them directly. The examples reflected their reality. The proof we highlighted came from similar companies. We also quietly removed features from the main story that were not important for that segment.
Lead volume did not explode, and that was fine. The quality improved. Sales discussions became more concrete. Prospects started to say things like “This feels like it is built for our situation.”
The lesson is that being specific feels risky at first because it seems like you are turning people away. In practice it makes everything easier and clearer.
Common Myths About Validation That Design Work Exposes
Certain wrong beliefs show up again and again when teams talk about validation.
One common myth is that a friendly survey is enough. Founders send a form to people they know. The answers come back full of positive language. “Yes, this seems useful.” “I would consider using this.” That is not the same as “I am ready to pay and change how my team works.”
Another myth is treating compliments as evidence. The team shows a shiny prototype or brand to friends and hears “Love it, looks great.” People rarely want to discourage someone face to face. Until someone offers serious time, budget, data, or organisational access, those compliments are nice but they are not proof.
A third myth is placing too much weight on vanity metrics. Traffic numbers without context. Email lists that go quiet. Social engagement with no follow up. These are easy to add to a slide and easy to misread.
Good design work during validation helps cut through these illusions. A focused landing page with a clear call to action gives harder data. A prototype session where someone struggles through a flow shows more truth than ten enthusiastic comments on a static mockup.
A Simple Three Week Validation Sprint That Uses Design Properly
When we run a short validation sprint, we try to keep a steady rhythm. There is enough structure to avoid wandering and enough flexibility to adapt if something surprising appears.
In the first week the focus is on clarity and conversations. Together with the founder, we define one target audience and one main problem in plain language. Then we talk to real people in that audience. Five to ten calls where we mostly ask them to show how they handle this work today. We note phrases they use, tools they rely on, and points where they slow down or complain.
From those notes we draft a simple value statement and a first version of the story. At this stage the words can feel basic. That is usually good.
In the second week we build and connect the experiments. We design and publish a focused landing page. We create a clickable prototype of the core flow. We share the page and the prototype with the people we spoke to and, when it makes sense, with a few new contacts. Traffic does not need to be large. The focus is on reaching the right people.
In the third week we look at behaviour and make a choice. How many visitors reached the core story. Who clicked the main action. Who booked calls. How did conversations change once people had seen the page and tried the prototype. Which objections repeated.
At the end there is a deliberate decision. Do we push this idea further, adjust the target audience, change the promise, or park it. The worst pattern is endless validation with no conclusion. A sprint with a clear ending forces a decision, even if that decision is “not now.”
When To Stop Validating And Commit To A Real Build
Founders rarely feel fully ready to stop validating. There is always one more experiment that might be interesting.
At some point, constant validation becomes its own form of avoidance. The team circles the same idea without giving it a fair chance in the market.
The question is not “Do we have perfect data.” It is “Do we have enough real signals to justify a serious bet on the next phase.”
Patterns we look for include hearing similar language and frustrations from the same type of customer, conversations becoming easier to start, and at least a small cluster of people actively pushing the project forward. They ask “When can we try this in production.” They introduce colleagues. They follow up on their own.
In more concrete terms, if a team has had more than ten serious conversations within one clear segment, a few of those contacts have committed to pilots or early contracts, and the team has run at least one or two landing page and prototype cycles without discovering major problems, that usually justifies moving into focused product work and a proper website.
Learning does not stop after that. The difference is that now design and development time is being spent on something that already has a base of reality under it.
Where A Design Agency Can Help In Validation
A lot of this can be done internally with simple tools, time, and a willingness to hear uncomfortable feedback.
There are moments though where it helps to involve a team that is not attached to the idea yet and can look at it with clear eyes.
A UX design partner can make validation faster and more honest. They can turn the messy thoughts in the founders head into a coherent story on a page. They can turn raw call notes into a lean prototype that people can actually click. They can spot when the landing page, the deck, and the conversation all tell slightly different stories.
At Webgamma, this is often where we step in. A founder is past the napkin stage but not ready to commit to a large rebrand or complex build. Together we design a short validation cycle that uses landing pages and product flows as experiments, not just as pretty assets.
Whether a team works with us, another creative agency, or keeps everything internal, the principle stays the same.
You validate an idea by watching how real people respond to a clear story and a believable experience. Not by collecting opinions about a concept that never leaves your slide deck.
When the site and the prototype are treated as living experiments instead of static showcases, the idea gets a fair chance to prove itself before months of design and development go into it.
