What you will learn
- How to describe one user task instead of “make a website”
- How to build a page in parts: structure, styles, behaviour
- How to check a page on a phone and with a keyboard
- What must never go into a page’s code
Key terms
- HTML
- The structure of a page: headings, text, buttons, forms.
- CSS
- The styling: colours, fonts, spacing, adapting to the screen.
- JavaScript
- The behaviour: what happens on a tap, form submission, animation.
- Responsive design
- A page that is equally convenient on a phone, a tablet and a computer.
01Describe one scenario
Choose a user and one action: find a document, submit a request, open a catalogue. Write down what the person sees before the action and what they get after it. That is the task for the first version.
Example. “A streamer opens the page, understands within 10 seconds that donations arrive straight in their wallet, and taps ‘Create a link’.”
02Build in parts
Ask the AI for the HTML structure first: a heading, a description, three benefits and one button. Then the styles, then the behaviour. Check each part in the browser before moving on to the next, so an error is easy to find.
Tip. Ask for short comments in the code: it makes the code easier to maintain.
03Check on a phone and with a keyboard
Open the page on a narrow screen: nothing should stick out past the edge, and the buttons should be easy to tap with a finger. Go through the page with the Tab key: every link and button should get a visible focus.
- 360 pixels wide with no horizontal scrolling
- Main font no smaller than 16 pixels
- Form fields have labels
- All links work
04Security
Everything in a page’s code is visible to any visitor. API keys, passwords and tokens never go into a page’s code: they are kept on a server.
- Do not paste keys and passwords into HTML and JavaScript
- Do not include scripts from unknown sites
05Get ready to publish
Add a clear page title (title) and description (description): search engines show them. Check that images have descriptions (alt) and that the page opens quickly on a mobile connection.
Before publishing
- The page solves one clear scenario
- There is no horizontal scrolling on a phone
- All buttons and links work and can be reached with a keyboard
- There are no keys, passwords or tokens in the code
- There is a title, a description and image descriptions
Common mistakes and what to do instead
Asking the AI to “make the whole website” at once
Start with one scenario and build in parts.
Checking only on a computer
Most visitors come from a phone.
An API key right in the page code
Secrets are kept only on a server.
Publishing without a title and description
Without them, the page is harder to find in search.
Try it yourself
Build a page for your project: a heading, a description, three features and one working action.
- Describe the user scenario in one sentence
- Get the HTML structure from the AI and check it in the browser
- Add styles and check at 360 pixels wide
- Go through the page with the Tab key and note what you find
Result. A working page and a list of the checks it has passed.
Test yourself
Answer in your head first, then reveal the answer.
1Why is it better to build a page in parts?Answer
You check each part right away, and an error is easy to find. A large block of code is hard to debug.
2Can you store an API key in a page’s JavaScript?Answer
No. Any visitor can see a page’s code, so keys are kept on a server.
3How can you quickly check a page’s accessibility?Answer
Go through it with the Tab key: all buttons and links should get a visible focus.
In short
One scenario, building in parts with checks in the browser, a phone and a keyboard, no secrets in the code, a clear title and description. That is how a first page ends up working, not just looking good.