跪拜 Guibai
← Back to the summary

From One Sentence to a Dashboard Draft: A Structured AI Skill for Designers

Challenge: Generate a Visual Dashboard Design Draft with One Sentence

Author: Gyrate Tags: AIGC, Design, Visual Design

image.png

Introduction

The emergence of ChatGPT Image 2.0 has brought another leap forward in the design of data visualization dashboards. I've been thinking recently: if a user just says, "I want to make a smart port dashboard," can AI directly generate a usable design draft for us?

My judgment is: directly generating the final draft may not be realistic, but generating a "designer starter draft" is feasible.

Goal

I didn't define it as a "dashboard auto-generator" from the start. That goal is too big and easily becomes a gimmick. A more practical positioning is: one-sentence generation of a visual dashboard design draft, used for designer kickoff, pre-sales proposals, product prototypes, and business communication. The value of such images is not final delivery, but quickly aligning on a few questions:

  1. What is the actual theme of this dashboard?
  2. Should the central visual be a map, park, port area, farm, or business architecture diagram?
  3. What business charts should be placed on the left and right sides?
  4. Is the overall vibe a clean medical style, port dispatch style, agricultural supervision style, or government operations style?
  5. Do the client, product manager, and designer agree on this direction?

If these questions aren't aligned, AI directly generating an image will likely result in a wallpaper that "looks like a dashboard." The picture might be beautiful, but the charts lack business meaning, the main visual and indicators don't match, and ultimately it can't enter a real workflow. Therefore, I made this tool a skill, rather than just writing a simple prompt.

Idea Conception

The initial envisioned process was simple:

  1. User sends a message: "I want to make a port dashboard."
  2. AI first generates a corresponding confirmation plan brief.md for user confirmation.
  3. User can adjust the scenario, main visual, objects, indicators, and the title and content of each chart panel.
  4. After confirmation, select a visual style, offering several style directions, including reference images and text descriptions.
  5. Set output format and aspect ratio; default to png, 16:9 if not specified.
  6. Then generate the image plan.
  7. Later, if the direction is confirmed, consider converting to SVG or importing into Figma for secondary design editing.

There's an important trade-off here: don't promise "direct generation of editable SVG" upfront.

Because the real difficulty now isn't generating an SVG file, but making that SVG simultaneously meet visual quality, layer structure, component reuse, and editability. If you force editability in the first stage, you'll get stuck on visual effects. So I currently prefer to first generate high-quality bitmap concept images, and after the direction is confirmed, break it down into a structured plan, layout blueprint, and component mapping, and then enter the SVG/Figma stage.

Overall Skill Process

The entire skill is broken down into 5 stages.

1. Understand the Requirement in One Sentence

The user's input might be very short, for example:

  1. I want to make a port dashboard.
  2. I want to make a smart medical dashboard.
  3. Guangzhou Nansha smart building, main body reference this image.
  4. Smart agriculture data visualization dashboard, main body is a certain farm.

Here, AI shouldn't generate an image immediately. Instead, it must first determine a few basic questions:

  1. What is the industry theme?
  2. What is the business scenario?
  3. Who is the target user?
  4. What should the main visual express?
  5. What business issues should the charts revolve around?

2. Generate brief.md for User Confirmation

brief.md is the most critical step in this process.

It's not a formality, but to prevent AI from drawing randomly. When a user says one sentence, AI needs to translate that sentence into a discussable plan.

I require the brief to include at least the following:

  1. Dashboard title
  2. Target users
  3. Usage scenario
  4. Design goals
  5. Main visual suggestion and rationale
  6. 6 chart panels
  7. Title, expression form, business question, field, and data description for each chart
  8. Assumptions that need user confirmation

For example, when making a small-area smart agriculture supervision dashboard, AI shouldn't just write "put a line chart on the left and a pie chart on the right." It should clearly write:

  1. The central main visual is a farm bird's-eye view scene + heatmap layer + crop layer.
  2. The left side can display regional agriculture core status, environmental heat trends, and plot status matrix.
  3. The right side can display crop planting structure, sensor and equipment online status, and abnormal plots and disposal closure.
  4. The crop layer should reflect crop name, temperature, water content, fertility, and risk status.

This gives the user a chance to adjust the plan before generating the image. If the user thinks the main visual is wrong, the indicators are wrong, or the scenario is wrong, they can directly modify the brief without waiting for the image to be generated and then starting over.

3. Select Visual Style and Output Specifications

After the brief is confirmed, enter the visual style selection. Here, you can't just give vague labels like "tech blue, dark style, light style." The color and texture of the dashboard should relate to the industry, client, and usage scenario.

For example:

  1. Medical: tends towards white-blue, ice blue, light cyan, emphasizing hygiene, cleanliness, and order.
  2. Port: usually can go with blue-green tones, but if the user specifies purple and white, it should be adaptable.
  3. Agriculture: can go with green, but shouldn't be a cheap bright green, nor like an ordinary white-background backend system.
  4. Buildings and parks: can lean towards light tech style or urban operations style.

Default output specifications are currently set to:

  1. Format: png
  2. Aspect ratio: 16:9
  3. Size: 1920x1080

The value of this stage is to first fix the visual atmosphere, avoiding the need to rely on a long prompt for temporary descriptions each time.

4. Generate Image Plan

The actual image generation happens in the fourth step. The prompt here will forcibly include the confirmed brief, layout rules, chart content, and visual style. Especially emphasize one point: if the user only asks to change the color tone, the chart content should not be changed.

This problem was encountered during testing. For example, the first version of the agriculture dashboard had a decent content structure, but the white panels and background didn't look good. Later, when changing to a dark green agricultural tech style, AI easily replaced the chart types and content as well. At this point, the prompt must clearly state: only change the visual style, do not change the chart titles, fields, panel content, or business structure.

In other words, the focus of the image generation stage is not "free play," but "play within the confirmed plan."

5. Subsequent SVG/Figma Direction

Only after the image plan is confirmed does the subsequent structuring begin. This step is not the focus of the first stage yet. My idea is to first smooth out the pipeline from "one sentence to image starter draft," and then gradually solve the layer editing problems of SVG and Figma.

The reasonable path should be:

  1. Confirm bitmap concept image.
  2. Extract structured proposal.json.
  3. Generate layout blueprint.
  4. Establish chart component and asset mapping.
  5. Generate dashboard.svg.
  6. Then import into Figma for secondary design editing.

Core Rule Design

The value of this skill is not just the prompt, but turning dashboard design experience into underlying rules.

Without these rules, AI-generated dashboards have several typical problems: charts look like decorations, left and right panels are too monotonous, main visual and charts are disconnected, colors are always tech blue, and the picture looks lively but lacks business focus.

So I first consolidated several types of rules.

1. Layout Rules

Currently, a fixed top-bottom structure is adopted:

  1. Top: title, time, status, alerts, etc.
  2. Main area: left and right sides are fixed-width chart columns.
  3. Center area: main visual, such as map, park, building, port area, farm, business architecture diagram.
  4. Default: 6 chart panels, 3 on each side.

The fixed layout isn't because it's perfect, but because the first stage needs stability. There are already many variables in a dashboard design draft. If the layout is completely open from the start, AI can easily make the picture scattered. After the basic pipeline is stable, expand to layout templates like horizontal dispatch type, map-dominant type, architecture diagram-dominant type, and operations cockpit type.

2. Chart Expression Rules

You can't apply the same line charts, pie charts, and bar charts to every industry. Charts should start from business problems, not from a chart library.

For example, a port dashboard is more suitable for berth status, yard heatmap, quay crane operations, container truck flow, and anomaly closure; a medical dashboard is more suitable for bed water level, patient flow, department load, emergency congestion, and resource utilization; a building dashboard can focus on floor equipment matrix, energy structure, people flow trends, parking water level, and work order closure; an agriculture dashboard is more suitable for plot status matrix, environmental heatmap, crop structure, sensor online status, and anomaly disposal.

Later, I specifically added a chart expression library to the skill, providing more choices during the brief stage. This way, AI won't mechanically generate "line chart on the left, pie chart on the right" every time.

3. Zhongke Smart City Aesthetic

This rule is to constrain the visual atmosphere. I want the generated dashboards to be closer to what enterprise and government clients can accept, rather than cheap, flashy visuals.

So I added a few constraints:

  1. Professional, clean, acceptable to enterprise/government clients.
  2. Emphasize order and solution sense.
  3. Less cheap flashiness, no random neon, excessive cyberpunk, or meaningless light effects.
  4. The picture shouldn't be too filled; it needs breathing room.
  5. Charts and main visual should blend as much as possible, not each panel looking like a rigidly pasted white card.

4. Color Rules

AI easily makes all dashboards with dark blue backgrounds, cyan wireframes, and neon borders. In the short term, it looks like tech style, but over time, there's no industry differentiation. So I changed the color rules to follow the industry:

  1. Medical: white-blue, ice blue, light cyan.
  2. Port: blue-green as primary, also supports user-specified purple-white.
  3. Agriculture: green as primary, but control saturation to avoid cheapness.
  4. Government/Parks: low-saturation blue-green, gray-blue, light tech.

Color rules aren't just for aesthetics; they also let clients perceive the industry attributes at a glance.

Implementation

This skill itself isn't complex enough to require writing a whole system; it's more about organizing the process, rules, templates, and helper scripts clearly. The current main structure is:

data-screen-concept-builder/ SKILL.md references/ brief-template.md design-rules.md chart-expression-library.md visual-styles.md svg-handoff.md scripts/ create_brief.py scan_assets.py archive_image.py

SKILL.md defines when to use this skill and the complete workflow. brief-template.md constrains the structure of the confirmation plan. design-rules.md writes the underlying design rules. chart-expression-library.md expands data expression forms for different industries. visual-styles.md manages style options.

Several scripts do auxiliary work:

  1. create_brief.py: generates an initial brief from one sentence.
  2. scan_assets.py: scans local assets like charts, subjects, and reference images.
  3. archive_image.py: archives generated images into article or project directories.

The key here isn't code complexity, but making AI know what to do and what not to do at each step. The skill's role is to fix these constraints, avoiding the need to manually patch prompts each time.

Example Results

The following images are different directions generated during testing.

The medical dashboard direction is "hospital-level operations status / hospital area status + business architecture." Such scenarios shouldn't be too dark or too cyberpunk; overall, white-blue, ice blue, and light cyan are more suitable for a clean and tidy feel.

The building dashboard referenced the main image provided by the user. The focus wasn't on reinventing a building, but on blending the building's main visual, operations indicators, and left-right charts.

The port dashboard was understood as "port dispatch operations status," with the main visual using a port bird's-eye view scene + dispatch link. In this case, the user specified purple and white, so blue-green wasn't forced.

The agriculture dashboard iteration best illustrates the problem. The first version had a decent content structure, but the white panels and background looked like an ordinary backend system.

These images are not final design drafts, but they can already serve as designer starter drafts: you can see the theme, main visual, chart structure, color direction, and overall vibe. After the designer takes over, they can continue optimizing layers, fonts, chart details, and real data.

Applicable Scenarios and Boundaries

This skill is suitable for the following scenarios:

  1. Dashboard concept images in pre-sales proposals.
  2. Product managers exploring prototype directions.
  3. Designer starter drafts and visual direction exploration.
  4. Business teams quickly confirming dashboard themes, chart structures, and main visual directions.

It may currently not be suitable for directly undertaking these tasks:

  1. Directly generating deployable frontend engineering.
  2. Directly replacing designers for final drafts.
  3. Production systems with strict requirements for real data accuracy.
  4. Generating fully editable, high-quality SVG or Figma files in one step.

In other words, it's currently more of a front-end productivity tool: helping teams quickly go from a vague requirement to a discussable design starter draft.

Summary

The truly valuable part of this isn't having AI draw a flashy picture, but fixing the pipeline of "understand requirement - generate brief - user confirmation - select style - generate image - subsequent structuring." Only by embedding industry understanding, chart expression, visual rules, and team aesthetic into the skill can AI-generated images have a chance to enter a real workflow.

At this stage, it's more suitable as a designer starter draft and proposal communication tool. After the brief structure, component mapping, and SVG/Figma conversion pipeline stabilize, there's a chance to further evolve into a more complete dashboard design production tool.

This Skill still heavily relies on Image 2.0's image generation model. Interested friends can help test and send me feedback. Also, now that Codex's mobile remote control feature is out, you can really experience the satisfaction of generating a dashboard with one sentence on your phone.