How the app gets designed now
Sketch it first. Argue with it. Then let it build.
Wireframe mode is a step that happens before any real work starts. You get a rough sketch of every screen, you say what is wrong with it in ordinary words, and only once you are happy does anything get made properly.
01 — The problem it solves
The first attempt sold an app that did not exist.
Ask a computer to build an app and it will do exactly what you asked. Every button works, nothing crashes, and the result is this. Start with the website it wrote to advertise the thing:
The headline is fine. The dark green is a choice nobody made on purpose. But look at the phone on the right, in the spot where a website is supposed to show off the product: the screen is an empty grey smudge. A gradient standing in for an app.
It could not show the app because there was nothing worth showing. Here is what was actually behind that gradient at the time:
A greeting, one card of text, and then a list of five links. Checkpoints, Firsts, Photos, Calendar, Growth, each with a little arrow. The bottom third of the screen is empty.
This is a table of contents, not an app. It is what you get when software is told what features to include and nothing else: it includes them, in a list, in the order they were mentioned. Every one of those links works perfectly.
Nothing here is broken, which is exactly what makes it hard to fix by complaining. The software had no picture of a finished thing, so it satisfied the requirements and stopped.
02 — What a wireframe is
A grey sketch, on purpose.
A wireframe is a deliberately ugly drawing of a screen. No colour, no photographs, no logo. Just labelled boxes showing what sits where, and in what order.
Stripping the beauty out is the entire trick. When a screen is pretty, people react to the prettiness. When it is grey boxes, the only thing left to discuss is whether the right things are on the screen, which is the decision that actually matters and the one that is most expensive to get wrong later.
Two things worth noticing. Every box has a label saying what it is for, so nothing appears on a screen without a reason. And the row of buttons along the bottom is identical on both screens, because it is one piece of the design reused rather than drawn twice. Drawn twice, it drifts.
03 — The part you do
Say what should move.
These sketches are made of the same material as a web page, not painted like a picture. So changing one is an edit rather than a redraw, and it comes back in seconds looking exactly as before except for the thing you asked about.
You do not need the vocabulary. Plain sentences work:
Look at the structure
Is the important thing at the top? Is anything missing? Is there so much on here that a tired person would give up?
The numbers should be above the photos. Someone checking in wants those first.
It redraws, and keeps the old one
Every version is saved, so changing your mind costs nothing. A direction you dislike is one step back rather than a week of work.
You approve the structure
Once approved, that arrangement becomes binding. The polished designs and the finished app are both checked against it, so a screen cannot quietly lose a feature or grow one nobody asked for.
Only then does it get beautiful
Colour, typefaces, illustration and, if the app suits one, a character. All of it arrives afterwards, filling in a structure that has already been agreed.
04 — The difference
Same app, same features, both built by the machine.
On the left, what came out when the software was handed a list of requirements. On the right, what came out when it was handed an agreed structure first. No new features were added between these two columns.
One thing leads. The photo is the reason a parent opens the app, so it is large and first. Underneath, the day's summary says what has happened and who did it. The list of links is gone, because a list gives five things equal weight and therefore gives none of them any.
There was no chart. The old screen answered "how is my baby growing?" with a table of three rows and a paragraph about which parts cost money. The new one leads with the number people came for and draws the range a child that age usually falls in behind the line, so it means something without anyone explaining it.
The empty half reads as an invitation. Things already recorded carry their photograph. Things still to come are drawn as soft outlines rather than blanks, so a half-finished grid feels like something to look forward to instead of a list of things you have failed to do.
05 — Doing this with your own app
What it needs from you.
Less than you would expect, and none of it technical. Describe the app in a paragraph: who it is for, what they are trying to get done, and the two or three apps you would like it to feel like. Name any competitors you know of, because it reads them and works out what your version has to have before anyone would take it seriously.
From that it proposes the list of screens. You cross things off and add things it missed. Then the grey sketches arrive and the conversation above begins.
A useful thing to know: a character or mascot is a choice, not a default. A children's app is carried by one. A professional tool is undermined by one. That gets decided once, up front, from what the serious products in your field actually do, and it holds for everything afterwards.
Being straight about the limits
- It is a sketch, not a promise. The polished pictures are there to judge the feel. Real figures come from the real data once it is connected.
- Taste is still yours. It can copy how the best products in a field are put together. It cannot tell you which of two good directions is right for your business.
- The last mile stays human. Paying the app stores, and signing off what the app says about your customers' privacy, are your name and your responsibility, not the machine's.