AI Design Workflow That Actually Works in 2026: How We Do It at Pulsebay

How we're using AI to move from client requirements to websites and interactive prototypes, validate ideas earlier and bring design closer to development.

AI has made it easier to turn an idea into a first screen. But a first screen is not a finished product. The real work begins when that screen needs to reflect a brand, support real user journeys and make sense as part of a wider system.

At Pulsebay, we're using AI as part of that process, not as a replacement for it. It helps us explore directions, create and refine interfaces, and get to something tangible earlier. We then bring in the design judgement, product understanding and review needed to make the output useful.

Here's what that looks like in practice, through two projects with different goals: Elite Estate & Trade Rewards and TEWAKA.

The gap between generating a screen and designing an experience

When we first started exploring AI for website design, the immediate benefit was speed. We could describe an idea, generate a layout and get a visual direction much faster than starting with a blank canvas.

The first output, however, was rarely ready to use. Layouts could feel repetitive, visual hierarchy wasn't always clear, components lacked consistency and important interactions were sometimes missing. AI was responding to the instruction in front of it, not necessarily understanding everything the product needed.

A landing page can be generated from a relatively simple prompt. A complete experience has to account for what happens next: registration, user accounts, payments, different user roles, edge cases and the smaller decisions that connect one screen to another.

That changed how we approached the work. Instead of asking AI to design the product in one go, we began establishing the requirements and design direction first, then using AI to accelerate specific parts of the creation process.

AI helps us create faster. Our job is to make sure we're creating the right experience.

Before the interface, understand the product

A client brief is a starting point, not always a complete design specification. Some workflows are still being worked out, certain user scenarios are easy to overlook, and requirements can change as the project develops. If those gaps remain hidden, they tend to appear later, often during a design review or once development is underway.

We use AI early in the process to help break down the brief and explore the questions that shape the experience: who will use the product, what each user needs to do, which journeys matter most, what happens when a workflow is incomplete, and which details still need clarification from the client.

The value is not that AI makes those decisions for us. It helps organise the information, surface possible scenarios and make gaps easier to discuss. We still validate the requirements and decide what belongs in the product.

From an early website direction to a considered experience

Elite Estate & Trade Rewards is one example of where this approach came together. For this project, we used AI to create the public-facing website and move more quickly from the product direction to a working website experience.

The early direction gave us a useful starting point. From there, the work was about making the interface feel specific to the product: clarifying the message, improving the hierarchy, refining the search experience and giving the rewards concept a clearer visual explanation.

This is an important distinction in AI-assisted design: the first generated result is material to work with, not a design decision in itself. We review it against the brief, decide what is working, identify what is unclear and keep refining until the experience fits the product.

The same approach carried into the wider product. Alongside the public website, we developed a 57-screen clickable HTML prototype covering the broader experience. It gave the client something they could navigate, rather than a set of disconnected references. We could walk through individual workflows, review each phase and identify places where the prototype needed to align more closely with the written requirements.

Why we make the prototype clickable

A visual design explains how an interface should look. For products with multiple roles and workflows, it is also important to show how the interface should behave.

That is why HTML prototyping has become a useful part of our process. A clickable prototype lets us connect screens, demonstrate what happens after an action and review the states that a static design might not communicate clearly. It also gives clients a more concrete way to respond: they can experience a journey and point to the part that needs to change.

For Elite Estate & Trade Rewards, the prototype helped bring the public website and the different product areas into one navigable experience. It made phase-by-phase reviews more practical and helped expose missing requirements before full development.

A prototype is not the finished application. It is a way to make the proposed experience visible, testable and easier to discuss.

TEWAKA: showing how the workflow behaves

Our work on TEWAKA demonstrates a related use of prototyping. The project includes an admin web console and a driver mobile experience. We created clickable HTML mockups to communicate the structure and behaviour of those experiences to the client and development team.

On the driver side, the prototype brought together key journeys such as signing in, starting a shift, viewing trips, completing vehicle checks, managing breaks and recording refuelling details. Rather than presenting each screen on its own, we could move through the journey and inspect how one action led to the next.

That browser-based review also made small but important issues easier to catch. We could check whether forms fit within their cards, whether buttons led to the expected screen, whether default values behaved as intended and whether the layout held together at the target viewport.

The TEWAKA mockups were prototypes, not a production application: they did not include a backend integration. Their purpose was to serve as a visual and behavioural reference. We also prepared specifications for important features so the expected behaviour was clearer for development.

A workflow that brings feedback forward

Traditionally, a project might move from the client brief to requirements, Figma design, review, developer handoff and then development. That sequence still has its place, but it can leave some product questions unanswered until relatively late.

Our evolving approach brings exploration and validation forward. We start with the brief and a design foundation, use AI to explore and create, build an interactive prototype where it adds value, and review the experience with the client before preparing it for development.

BRIEF → DESIGN FOUNDATION → AI EXPLORATION → HTML PROTOTYPE → CLIENT REVIEW → DEVELOPMENT

In practice, the process is not strictly linear. Feedback can take us back to an earlier stage. A prototype may reveal a missing requirement; a client review may change the priority of a workflow; a browser check may show that an interaction needs another pass. That iteration is part of the process, not a detour.

Once the experience is aligned, we refine the design and document the expected behaviour so the development team has a clearer reference.

What makes the difference is the work around the AI

The biggest improvement is not simply that we can generate interfaces faster. It is that we can move between exploration, refinement and validation more efficiently.

We can explore more than one direction without spending too much time on repetitive early work. We can get feedback on a working journey instead of asking clients to imagine how a static screen might behave. And when screens are connected, missing interactions and inconsistent workflows become easier to spot.

That does not mean AI removes the need for design review, testing or product thinking. Generated interfaces still need to be checked. Interactions still need to be validated. Requirements still need to be understood in the context of users and business goals. AI can help with production, but responsibility for the experience remains with the people designing it.

What we've learned so far

Working with AI across different projects has changed how we think about the role of a designer. We've learned not to measure the success of an AI workflow by how much it generates. We measure it by how much it helps improve the final product.

• A good prompt cannot replace a clear understanding of the product.
• Generating screens is easy; connecting them into a consistent experience takes design thinking.
• Interactive prototypes can reveal problems that static designs may not expose.
• Client feedback is more useful when there is something tangible to review.
• AI works best when guided by clear requirements, a design foundation and continuous refinement.

Designing with AI, not handing design over to it

AI will continue to change how digital products are designed and developed. The tools will become more capable, and the time needed to turn ideas into working experiences will continue to decrease. But faster production does not automatically lead to better products.

At Pulsebay, we're focusing on using AI where it genuinely improves the work, from exploring requirements and creating websites to building interactive prototypes and improving communication between design and development. Not every project needs the same tools or the same process. The important part is knowing where AI can help and where human judgement is essential.

AI makes production faster. Design thinking makes the output better.

That's how we're approaching AI-assisted design at Pulsebay.