What a UX Designer Learnt from Building Apps with AI

UX designers know the gap. You can design something. You can prototype something. You can describe something in exhaustive detail. But turning that description into something a real person can use is another matter. That is usually where engineering support comes in. 

Derrick Ng, a UX designer at GovTech, spent months exploring that gap from the other side. Using an AI-assisted app builder called Lovable, he built small functioning apps on his own.

His experience offers a practical look at the possibilities that AI-assisted development offers designers, and where product judgement, technical vocabulary, and engineering expertise still matter. Here are three lessons from Derrick’s experiment: 

Lesson 1: Prototyping now goes much further than it used to 

Planning poker may sound like a game, but in software development, it refers to an agile estimation method. Team members use it to estimate the effort required for different tasks, often by assigning “story points” before revealing their estimates at the same time. This helps teams discuss differences in judgement before agreeing on the workload involved. 

Derrick’s team had been using an online Planning Poker tool, but its free trial ended. Rather than pay for another subscription, he decided to see if he could build a simple version himself as a pet project. 

To work properly, several users had to join the same session and reveal their estimates at the same time. This is the kind of task that would usually require engineering support.  

With an AI-assisted app builder, Derrick was able to get much closer to a working version on his own. But the process also showed where AI assistance has its limits. When Derrick tried to make the app support real-time interaction, the AI tool kept attempting solutions that did not work. He described it as entering an “error loop of death”.  

He only got unstuck when a developer told him that the feature he needed was called a WebSocket. Once he had the right technical term, the tool could help him move forward. This scenario captures both the power and the limits of “vibe coding”, where users describe what they want in plain language and let AI generate the code. AI could help Derrick solve the problem, but the missing ingredient was knowing what to ask for. 

Lesson 2: The better the brief, the better the prototype 

If AI can generate an app, do skillsets like design, product thinking or other technical domain expertise still matter? 

For Derrick, the answer was yes. AI-assisted development could help him move quickly, but the quality of the output still depended on the clarity of the input. 

When he wanted to explore different ways the app could work, he found it useful to take a jobs-to-be-done approach: describe the user problem, then let AI suggest possible solutions. For designers, this mirrors a familiar concept in the design process: diverging before converging. When the goal is to explore, a problem-led prompt can help open up possibilities. 

But when the direction is clearer, the brief needs to become more specific. If the goal is to build something based on a defined idea you already have, a detailed product requirements document, or PRD, may be more useful. A PRD sets out what the product should do, who it is for, how it should behave, and what constraints it needs to meet. Giving AI that kind of specific instructions can help it produce a stronger starting point for a more complete app. 

Depending on where you are in the design process, either approach can be useful. That is why the fundamentals still matter. Visual craft, product judgement, user empathy, and design principles help a designer determine what to ask for, assess what the tool produces, and know when the output is not good enough. 

Lesson 3: A working prototype is not the same as a production system 

A designer who is good at building can prototype better, test earlier, and make more decisions independently. That changes how teams work together and what a small team can do in a week. Derrick built multiple working apps in a matter of days, each one demonstrating an idea end-to-end in a way that would previously have required engineering support. 

But a line is worth drawing carefully, especially in the public sector. A working prototype is not the same as a product that can reliably serve people at a scale. 

AI-assisted development tools can help a designer produce a functioning prototype quickly, one that shows how a service might function so a team can decide whether it is worth building at all. What AI-assisted prototypes cannot deliver is the architecture, security, and reliability required for public services at scale. That requires real knowledge and expertise.  

Building fast is not the same as building well. Understanding what you have built, and its limitations, is part of the responsibility that comes with AI capabilities. 

What this means for design practice in government 

For public officers, Derrick’s experience offers a practical reminder: AI-assisted tools are most useful when paired with clear problem definition and proper judgement to assess what they produce. 

If you are curious about AI-assisted tools, the most useful thing you can bring to them is not technical skill. It is clear thinking about the problem you are trying to solve. The sharper your brief, the better the output. The deeper your understanding of the work, the more you will be able to assess whether what the AI produces is useful. 

This sits within a wider shift in how public officers are using AI tools at work. GovTech’s AI tools, such as PlatformAI ↗ (opens in new tab) and Desk ↗ (opens in new tab), are part of that broader effort to help public officers use AI more effectively and responsibly in their work. 

For government digital services, the value is not just that teams can build faster. It is that more ideas can be made tangible earlier, tested more realistically, and assessed before engineering resources are committed. 

Design and engineering are not becoming interchangeable. But AI-assisted tools may make the relationship more collaborative earlier in the product development process, reducing the need to wait for a traditional “pass-the-baton” handoff from design to engineering. 

The boundary has moved, not disappeared 

Designers have always been able to imagine how something could work. What's new is being able to build working versions of these ideas. 

The lesson from Derrick's experiment is not that everyone should become a developer. It is that AI does not eliminate the need for knowledge. AI changes where that expertise enters the process. Designers still need developers to tell them what a WebSocket is. Interfaces still need designers who understand the problem. Prototypes still need engineers to build production systems that citizens can rely on. 

The boundary around what one person can take from idea to working prototype has moved. The human behind the tool is still what makes it worth using. 

You can read Derrick’s full reflections, including all 15 lessons from building his own AI-assisted apps, on GovTech’s Medium publication ↗ (opens in new tab).