I want more say in how a coding model designs an interface. “Clean and modern” leaves plenty of room for interpretation, so I wanted to explore what happens when I describe the look more closely. I started with a familiar screen: a test-results viewer. Some tests passed, some failed, and I need to find out why. That gives me a table, a few filters, and plenty of room to try different designs.
John Hartnup gave me the idea with his article AI-generated posters don’t have to be horrible. He asked for different poster designs using names such as Bauhaus and Swiss-inspired. Those names helped him explore a much wider range of appearances, and I wanted to bring the same approach to an application.
A style name gives me a starting point. From there, I can describe how the heading, controls, and results should fit together, then open the page and see how it looks. If the heading takes too much space, I can ask the model to shrink it and bring the results higher on the screen.
A coding assistant built these four examples in one session, using the same application and sample data. The screenshots show the working pages. I wrote the accompanying design briefs alongside the implementation and included later refinements in the prompt files. You can adapt those prompts to your own application, although a separate model run may produce a different result.
Start with something the reader needs to do
I chose a small application called Test Desk. It shows twelve tests from three modules in a checkout build, with search, outcome and module filters, sortable durations, and expandable failure messages. The sample names include returnsValidationErrorsForMissingShippingAddress. You probably have a few names like that in your own tests, so I want to give them room in the layout.
Across all four designs, I want to find a failed test and open its error message. The shared brief describes that task and the controls it needs:
Build a test-results viewer for a developer investigating a failed build. Show test name, class, module, outcome, duration, and previous outcome. Include search by test or class, outcome and module filters, a failures-only shortcut, reset filters, and duration sorting. Expand failed tests to reveal their error messages. Keep the full-run summary separate from the filtered result count.
I kept the demo in plain HTML, CSS, and JavaScript, so you can open the page and try the controls straight away. You can also take the brief into an existing application. Just tell your agent which stack and components to use, whether that means a React component or a server-rendered template.
That task also guides my feedback. “The summary takes too much room above the failed tests” tells the agent where to make a change and why I want it.
Give each direction its own layout
I wanted four clearly different designs, so each brief changes the arrangement as well as the colours. The summary might sit above the results or run down the side. Filters can stretch across the page or fit into a narrow panel. The same twelve tests remain in every version.
For each direction below, start with the shared functional brief and add the design request. Give the agent room to rearrange the page. In this example, I’m keeping the data and behaviour fixed while allowing the composition to change.
Swiss report: typography and alignment
Create a Swiss-inspired typographic report. Use an oversized, tightly spaced sans-serif heading, an off-white background, black text, and a strong red horizontal rule. Put the run metadata to the right of the heading, separated by a vertical divider.
Arrange the four summary counts in equal-width columns with large numerals. Keep filters in one horizontal band on desktop. Give the table a black header with white labels, thin row dividers, and a red marker beside failed tests. Preserve all data and interactions.
[
The heading takes up a large part of the page, and the red rule separates it from the summary below. The four counts sit in equal columns, with the run details beside the title. The large heading pushes the results further down the screen.
“Swiss-inspired” names the direction, and “equal-width columns” gives the agent a specific layout choice. Of course, I can adjust that choice later. A smaller heading would leave more room for results while keeping the same alignment and colour treatment.
Editorial: change the reading order
Treat this screen like an editorial report. Use a warm paper-coloured background, a large italic Georgia heading, serif summary numerals, and plain sans-serif table text. Use brown accents and fine horizontal rules to separate the content.
On desktop, put the four run counts in a narrow left column and the results in a wider right column. Place search across the top of the results column, with dropdowns and actions beneath it. Use underlined inputs, generous row spacing, and a table header defined by fine horizontal rules. Preserve all data and interactions.
[
The italic serif title brings this version closer to a printed report. The counts run down the left side, so the results and filters share the wider column on the right. Search stretches across that column, with the dropdowns and actions underneath. Fine lines separate the sections.
I kept the editorial treatment in the heading and summary numerals, with plain type for test names and controls. You can make that distinction in your own prompt too. If you like the heading in a reference image, tell the agent to carry that treatment into the heading of your application.
Workbench: put the controls beside the data
Design this as a compact developer workbench. Use a dark blue-black canvas, monospace typography, muted cyan actions, and pale coral failure indicators. Use a small 32px desktop heading and one inline strip of run counts.
On desktop, place search and filters in a narrow vertical rail to the left of the results. Give the table most of the screen width. Use compact rows, a blue-grey header, and subtle tinted backgrounds with a left border for failures. Keep status words visible. On mobile, move the filter rail above the horizontally scrollable table. Preserve all data and interactions.
[
For the workbench, I wanted to get to the results quickly. The small title and inline counts leave room for the table higher on the page, while search and filters sit in a narrow panel on the left. Monospace text and muted colours bring it closer to the developer tools I had in mind.
A request for “dark mode” addresses the colours. To get this arrangement, I also specify the vertical filter panel and compact summary. Those instructions bring the table higher on the page and put the filters beside it.
I prefer this direction for the test viewer because I can focus on the results straight away. The narrow filter panel leaves little room for the search placeholder, though. Keeping the label above the field lets me shorten the text inside it.
Neo-brutalist: use blocks, borders, and contrast
Use a bold neo-brutalist direction. Put a huge uppercase heading in a lavender panel with a thick black outline and a hard offset shadow. Set the run metadata inside a smaller outlined box within that panel.
Use separate outlined summary blocks, with a wider peach block for failures. Put the entire filter toolbar in an acid-yellow band. Use a black primary button, square corners, a black table header with white text, and outlined outcome labels. Keep table text at normal reading size and all decorative effects outside the text itself. Preserve all data and interactions.
[
The lavender title panel, peach failure count, and yellow filter band divide this page into large blocks. Thick outlines and hard shadows make the sections easy to pick out before reading their labels. The result has a much stronger graphic character than the other versions.
I kept the table text at its normal reading size and put the decoration around it. That instruction gives “bold” a specific scope: the panels and borders carry the visual treatment, while the text stays at a size suited to reading rows of results.
Give feedback on the rendered screen
The Swiss report’s heading leaves less room for the results below it. I would try this follow-up to bring them higher on the page:
Keep the red rule, typography, and alignment. The heading takes too much space above the results. Reduce it to 48px and put the summary counts in one compact row. Keep the current table text size and all controls.
You can try that follow-up against the Swiss version shown above. It keeps the red rule and alignment while changing the size of the heading and summary. The screenshots show the design before this suggested revision.
Expanding a failed test adds its error message to the table:
[
The message wraps inside the row, and you can select and copy its text. I can see how much space the expanded row takes and whether the long error message fits. If your agent can inspect the page, ask it to open a failure too. Otherwise, send it a screenshot of the expanded row with your feedback.
Sometimes I can point to a design I like more easily than I can name its style. A reference image gives me another way to start the conversation:
Describe this interface in terms of typography, spacing, alignment, colour, borders, and information density. Suggest two or three style terms that might help me request a similar direction. Separate visible characteristics from guesses about its influences.
I would check the description against the image and keep the terms that match what I can see. A suggested historical influence still needs its own research. For a design prompt, I can start with the visible details, such as a large serif heading or a narrow column of controls.
These terms describe different parts of a design. “Bento” refers to an arrangement of differently sized tiles, while “glassmorphism” points to translucent surfaces. Carbon is a design system with guidance for components and their behaviour as well. If your application already uses a design system, give the agent its documentation and components.
Carbon’s typography guidance describes compact typography for product tasks and more expressive typography for editorial pages. That fits the choice between the workbench and report versions here. I lean toward the compact treatment because I want most of the space for the test results.
Keep the words and the behaviour in the brief
Hartnup noticed extra text appearing as he explored his poster variations. In the application brief, I ask the agent to preserve the supplied labels, counts, and columns so the content stays fixed as the design changes.
In Test Desk, for example, I keep the full twelve-test run in the summary. The text above the table then tells me how many tests match my filters. I include both in the brief so the agent knows what each count represents.
Search, combined filters, reset, duration sorting, empty results, and expanded errors passed the coding assistant’s browser checks in all four versions. It also checked the layouts at mobile width. On a narrow screen, the controls wrap and the table scrolls horizontally inside its own region. You can try that in the demo.
I’d take the same approach to images on a developer-event page. A generated geometric illustration could share the palette and shapes of the HTML layout, so I would describe those details in both requests. I’d keep the headings, links, and buttons as real interface elements.
Top comments (0)