Why do some websites feel like slop at first glance?

Sometimes a site feels like slop before you have clicked anything. There is a grand promise at the top, three equally important cards underneath, and a button saying Get started. You recognise the arrangement, but you still cannot tell what this particular site will help you do.

Familiar components are useful. The uneasy feeling comes when the choices seem unrelated to the thing being offered: the same headings could sell a sewing class, a budgeting app or a place to keep recipes. To investigate that feeling, take a page meant to help someone book a sewing lesson. Can they find a date, a price and a place before clicking?

A screenshot can be beautifully composed while those decisions are still missing. That is a useful place to begin fixing what people call the slopware look. Changing the gradient will not supply the lesson time.

Give the screen a job

Write one sentence about the person arriving here: “I want to see whether I can attend a beginner sewing class next Saturday.” Now read the screen with that question in mind. A card saying Unlock your creativity leaves them looking. Beginner sewing · Saturday 14:00 · materials included gives them something to decide about. These are invented details for our example; your own page needs its real ones.

Before asking an agent to make the page more polished, give it those facts. Include what the person needs to decide, what information is available, and what pressing the main button actually does. If the button opens a list of sessions, See class dates is a useful label. If it reserves a place, the screen has more to explain, including which session and what the reservation commits them to.

Then give the screen an order. On this page the class and date matter before the studio's history. Put the details needed for that decision together. When every sentence is in its own card and every card has an icon, the reader has to reconstruct which things belong together.

A plain block of text may do the job. A card may do it beautifully too. Choose the grouping first.

Make a small visual vocabulary

Pick one main text style, a clear heading style, a few spacing values and consistent treatments for controls. Reuse them. If two buttons perform the same kind of action, the reader should not have to learn their appearance twice.

The shared names for these choices are often called design tokens. In my seviyorsevmiyor stylesheet, backgrounds, text, corner radii and status colours have named values rather than being chosen afresh on every screen. My desktop-style portfolio uses another vocabulary: windows, folders, a menu bar. Those are different worlds with their own repeated choices. Neither stylesheet, by itself, proves that the resulting page is easy to use; that takes trying the actual journey.

You can make a pink interface, a quiet one or a wonderfully peculiar one. Mood, play and recognition can earn their space. The person should still be able to find the class time and book a place. Personality becomes much more convincing when it survives the ordinary work of the product.

Make the promise match the button

Return to the sewing class. If the button says Book a place, follow the whole attempt. Does it identify the session, explain the price and distinguish a confirmed booking from a request still waiting? Those decisions are part of the design too. A change of colour cannot fix a confirmation that appears before the booking exists.

AI can help produce and revise this interface. Give it the actual class details, the action the button performs and the outcomes the screen must distinguish. Then try those outcomes yourself. We will build the technical understanding for that check throughout the book.

Try the screen with less flattering content

Replace the neat demonstration title with a long real one. Open the page on your phone. Enlarge the browser text. Look at an account with no records and one with many. Does the action still make sense, and can you reach it without hunting?

Ask someone unfamiliar with the page to find the class date and begin booking. Let them try before explaining. Record the place they hesitated and what information would have helped there. “The date was below the button, so I thought I had to commit before seeing it” is a much more useful revision request than “make it less generic.”

In NN/g's study of AI prototyping in a real redesign project, generated layouts often lacked the specific visual language and context the work required. Use that as a question to ask of your own screen, not a verdict based on its font or who made it.

Take one screen through this pass before redesigning the whole app. You should finish with a clearer task, an order for the information, and concrete changes you can check by using it.

Now choose one of those changes. Somewhere in the project is the file that produces the heading or button you want to alter. Before we can follow it to the screen, we need to know which folder the tools are reading. That small detail explains why a command that worked a moment ago can suddenly seem to do nothing.