How to prototype an app without design skills

You can prototype an app without design skills, because a prototype is there to test whether the screens and steps make sense, and looking good is no part of that. Paper, a slide deck or a simple wireframing tool is enough, and AI tools will now turn a written description into something you can click through. For an internal business application or a customer portal, a useful prototype takes between an afternoon and a few days, and it is the best preparation you can do before asking a developer for a price.

Decide what the prototype is for

A prototype answers a question. The usual ones are:

• do the people who will use this agree that it matches how the job is done?
• have we missed a step, a piece of information or a type of user?
• is this a small project or a large one?

Do not try to prototype the whole system. Choose the one or two tasks that matter most, such as “a customer requests a quotation and we approve it” or “an engineer completes a job sheet on site”. Write each task as a list of steps: who does it, what they need to see, what they type or choose, and what happens next. That list is already half the prototype.

Start on paper

Take one sheet of paper for each screen. Draw boxes for the things people fill in, lines for text and a labelled rectangle for each button. Beside each button, write which sheet it leads to.

Then try it on a colleague. Give them the first sheet and the task. When they “press” a button by pointing at it, swap the sheet for the next one. It feels like a game, and it finds a surprising number of gaps, such as a screen with no way back or an approval that nobody thought to include.

Two habits make paper prototypes far more useful:

• Use real examples. Write in real customer names, product codes and awkward addresses. Placeholder text hides the problems that real data reveals, such as a product description that will not fit on one line.
• Draw the phone version if phones matter. A screen that works on a monitor may need splitting into three on a phone.

If the process you are replacing already runs on a spreadsheet, you have a head start. The columns show what information is recorded, and the rows are your real examples. Turning a spreadsheet into a web application often begins with exactly that file.

Make it clickable

Once the paper version has settled down, a clickable version lets people try it without you standing beside them. We chose the tools below because each can be used by someone with no design training on the first day, and because we checked in October 2026 that each is still on sale and maintained.

Presentation software. PowerPoint, Keynote and Google Slides all let you link a shape on one slide to another slide. Make one slide per screen, draw the buttons as shapes and link them. There is nothing new to learn and everyone can open the result.

A wireframing tool. Balsamiq is built for this job. Its screens are deliberately plain, so nobody is distracted into arguing about colours. It is sold by subscription and has a free trial. Figma is a full professional design tool; it has a free starter plan and ready-made kits of buttons and forms, and it takes longer to learn.

An AI builder. Tools such as Figma Make and v0, from Vercel, take a description in plain English and produce screens that work when you click them. General AI assistants can do something similar. This is now the fastest way to get a realistic prototype, and your written list of steps is the ideal thing to give it.

AI-built prototypes need some care.

• They look finished. People who see one tend to assume the real system is nearly done. It is not: there is no proper security, no connection to your other systems and nothing tested with your data.
• Do not paste real customer or staff data into one. Make up realistic examples.
• Treat the result as a way of agreeing what to build. Whether any of the generated code is fit to keep is a question for a developer to answer after reading it.

Test it with the people who will use it

A prototype that only its author has seen proves very little. Put it in front of the people who will use the real thing: the staff who do the job today, or a few friendly customers if it is a portal.

You do not need many. Jakob Nielsen of the Nielsen Norman Group has long advised “testing no more than 5 users and running as many small tests as you can afford”, on the grounds that the same problems soon start to repeat.

For each session:

1. Give the person a task, and do not give them a tour. “A customer has rung to change a delivery date. Show me what you would do.”
2. Stay quiet and watch. Note where they hesitate, where they look for something that is not there and what they click first.
3. Ask what they expected to happen whenever they seem surprised.
4. Resist explaining or defending the design. If it needs explaining, it needs changing.

Ask about the awkward cases too. What if the customer has two delivery addresses? What if the order is part-shipped? These are where real systems grow complicated, and it costs nothing to discover them at this stage.

Change the prototype after each round and test again with different people.

What to ignore, and what to get right

Colours, logos, fonts and exact wording do not matter yet. Neither do the distinctions between a wireframe, a mock-up and a prototype, although our article on the differences between them explains the terms if a supplier uses them.

These are the things worth getting right, because they decide how big the project is:

• the order of the steps in each task;
• what information appears on each screen, and where it comes from;
• who is allowed to see and do what;
• what happens when something goes wrong or is left incomplete.

Hand it to a developer

A prototype makes a much better brief than a written description alone. When you approach a supplier, send:

• the prototype itself, as a link, a file or photographs of the paper sheets;
• the tasks it covers, and a plain list of what it leaves out;
• what you learned from testing, including the awkward cases;
• a few rows of realistic sample data.

Our software project planning worksheet gives you somewhere to gather the rest: the users, the other systems involved, the deadline. With those in hand, a supplier can price something concrete, which is what a fixed-price build depends on.

It is also worth asking each supplier what they would change in your prototype and why. A good one will find things you missed, and the answer tells you a lot about how well they have understood the job. Our companion article on the importance of prototyping explains what a supplier’s own prototype should then add.