What should you design before you build a web app?
A sketch helps you choose what people see. A clickable prototype lets them try the path. A working app has to keep its promise after the click, including when a request fails. Design and check those outcomes before adding more screens.
Which part of your app should you design first?
Design one useful task all the way through. If your app lends out tools, start with a borrower who needs to keep a drill for two more days. Show the date they already have, let them choose a new one, and tell them what happens after they ask.
Start with the words the borrower needs, even if your first sketch is a sheet of paper. “Extend my loan” gives them a clear action. “Your new return date is Thursday” lets them check the result. A page of finished-looking screens is hard to assess when you still have to explain what people should do.
Write down one rule before you draw the next screen. If another borrower has already reserved the drill, the original return date stays in place. That decision gives you a useful second route to design.
What should the screen show while it waits or when it fails?
Draw the successful path and the cases that leave the borrower with a decision. They should be able to tell which date the app last confirmed and whether the change is still being checked.
Write a short label for each field and explain problems in text. A red border may draw attention, but the borrower still needs to know what to do.
| Situation | What the screen should communicate |
|---|---|
| Ready to request | Show the current date and available new dates. Use one clear action to request the change. |
| Waiting for a reply | Keep the chosen date visible and say that the request is being checked. Show that the first click was received. |
| No dates available | Explain that the original date still applies. Offer a useful next step, such as checking later or contacting the library. |
| The app says the chosen date is taken | Show that the original return date still applies. Keep the chosen date visible so the borrower knows what was rejected, then offer another date. |
| The browser gets no reply | Show the last confirmed date and say the change is still unconfirmed. Check the saved loan. Offer a retry only if the app can confirm the change did not go through. |
| Change saved | Show the new return date as the result of the saved change. |
Compare tools
Scroll the table sideways to read every column.
| Tool | What do you start with?What you already have or need to prepare. | What can you try or share?The design, flow or copy another person can use. | What can you take with you?The files or design information the next step needs. | Which access or cost matters?What can change the choice before you rely on it. |
|---|---|---|---|---|
| Figma | Draw or edit screen layouts and connect the parts that someone can click. | Open a clickable prototype in the browser and share it for review. | Save an editable .fig copy if allowed. Export static assets separately. | Starter supports prototyping. A prototype-only link needs a paid plan. |
| Google Stitch | Describe the interface or bring sample images, text or code for context. | Connect generated screens and try the path in Play. Google documents sharing through AI Studio. | Export design rules as DESIGN.md. Google documents a screen export to Antigravity. | Check your account’s limits and the cost of anything you use to publish or run the result. |
| Adobe XD | Start with an existing file, an accessible account, or a review link you already have. | Open the existing design and check which prototype flows and links still work. | Save a local .xd copy and export important screens and assets separately. | Adobe maintains XD for existing customers. Check access in Creative Cloud before planning a recovery. |
| Sketch | Draw screens on a Mac or open an existing Sketch file. | Connect the screens and try the click path in a preview. | Save an editable .sketch file. A shared Workspace can give a browser reviewer measurements and prepared assets. | Editing requires a compatible Mac. Check whether you need browser review before choosing a license. |
| Penpot | Open the browser editor in a managed or self-hosted workspace. | Connect boards and play the result in View mode. | Keep an editable .penpot file and choose how to include the linked libraries. | People who have a prototype link can view its selected pages without an account. Self-hosting needs someone to run the workspace. |
| Framer | Lay out a marketing site or a page that presents a collection of content. | Try a responsive Web Page in Preview. Keep design explorations on a Design Page. | Transfer the project within Framer or export selected assets and CMS content. Full standalone site export is unverified. | A custom domain needs a paid site plan. Extra editor seats have their own charge. |
How can you try one complete flow before building it?
Use made-up dates and an imaginary loan. Work on paper or in a private prototype. Keep real records and connected services out of the exercise.
- Draw the starting pointWrite “Return on Tuesday” at the top. Add a Thursday option and an Extend my loan button. Give each detail one place on the screen.
- Play both outcomesDraw a confirmation for Thursday and a second outcome where Thursday is taken. In that second outcome Tuesday still applies. On paper, swap in the next sketch when the person points to the action. In a clickable draft, connect the same screens.
- Ask someone to try itSay “You need the drill until Thursday. See whether you can keep it.” Watch where they start and ask them what date they think they have at the end. Write down the first unclear word or action and revise it.
- Try a narrow layoutUse a phone-sized sketch or prototype view. Check whether the date and action stay easy to find. For a browser version, go through the flow with only the keyboard and check where the focus highlight goes.
- Write a test for the working appIn a private test copy, have the app save a made-up extension, refresh and check that the saved date is still there. Check that a confirmed rejection leaves the original date in place. In the test copy, simulate a lost reply after a save and check that the app finds the new date and offers no retry.
What should you hand over with a design?
Give the builder the editable design or a version they can view, the sample words and dates, and the rules for what the app should save. Say which parts already exist in the app so they can be reused.
Use a small handoff. Start with one narrow layout and one wide layout, the different outcomes from the table, and one thing the builder can check for each outcome. A picture can show the look. The note about Thursday being taken tells them which result the app must protect.
Keep the original design and any image or font permissions with your project. If you change tools, take one screen and a few important assets across first. Open them at the destination and check text, alignment and what you can still edit before moving the rest.
When do you need a different kind of design tool?
Choose by the work in front of you. A rough sketch is enough to compare two flows. An interface editor helps when you need to reuse a layout or share detailed feedback. A prompt-based canvas helps you explore directions from a description.
If you only need a logo, a motion asset or a collection of examples, look for a tool that does that job. If you already have an old design file, start by checking access and making a usable copy. The decision can be about getting work out safely, rather than choosing where to start a new project.
How do you know the built version is usable?
Repeat the task in the running test app and check the saved test record. If the app rejects the change, confirm the old date stays in place. If the reply goes missing, confirm the screen shows the last confirmed date while it checks the saved loan. Once it finds a saved change, it should show the new date.
Try a small screen, a long date label and the keyboard. Watch whether the borrower can find the same action on every relevant screen. Reuse the same button, spacing and words for the same job, and remove duplicate actions when one is clear.
Ask the person to tell you what happened after the change. If they can explain the final date but refreshing the page loses it, the screen gave a convincing answer before the underlying app was ready.