Grok Bot design workflow: From confusing cards to working code

The feedback cards in CRRT, the product we’re building, had a surprisingly difficult job: explain what needed review, what was ready for an agent, and what was finished. We had labels and a toggle, but the feedback I was getting was that people still found the statuses confusing. That gave me a useful test for a Grok Bot design workflow: could I work through an actual product problem, explore better options, and bring the design into the existing codebase?

I ended up with a redesigned card implemented in the dashboard, with more exploration still to do before a pull request. What made me want to keep experimenting was how accessible the process felt. I could ask for references, react to screenshots in the conversation, adjust the design in Paper, and ask Grok Bot to build the direction I liked.

For a designer, PM, or founder trying to get an idea into a form the team can evaluate, that is a useful place to start. Here is how I approached it, where I had to redirect the work, and what I would check before taking it further.

Try this workflow on your own product. Our free Grok Bot design guide walks you through eight steps, with prompts you can copy and a checklist for each stage. Get the free Grok Bot design guide →

Table of contents

• How does a Grok Bot design workflow work?
• Start with the confusing part of the product
• Use Mobbin references that match the interface
• Explore card UI design in Paper
• Bring Storybook components into the design-to-code workflow
• How to try this workflow on your own product
• What worked, and what still needed review

How does a Grok Bot design workflow work?

A Grok Bot design workflow uses an AI agent to help move a product change through research, visual exploration, feedback, and implementation. In my CRRT test, I used Mobbin for references, Paper for design exploration, and our existing Storybook components as the foundation for changes to the dashboard.

The connections between those tools mattered. MCP, short for Model Context Protocol, gives an AI application a way to work with connected tools. In this test, I asked Grok Bot to connect Mobbin, completed the browser connection step, and continued the conversation. That felt much easier than the setup processes I had worked through before.

Paper provided the space where I could inspect and adjust the concepts. Its MCP server supports reading and writing design files, which is what makes this kind of agent-assisted exploration possible. Paper’s MCP documentation explains the connection and setup requirements.

Start with the confusing part of the product

My starting point was the relationship between status and action. A label like “Needs review” tells you something about an item. “Send to agent” asks you to do something. Putting those ideas together without enough visual distinction can leave people working out what has already happened and what they are supposed to do next.

I wanted someone scanning CRRT’s dashboard to understand the state of a feedback item before opening it. I also wanted to explore whether they could move that item forward directly from the card.

So my initial request described the confusion and asked for inspiration before any redesign. I wanted to rethink the labels, their placement, and how clearly the card explained what was happening. That gave the exploration a question to answer: can someone understand this item and its next step at a glance?

Use Mobbin references that match the interface

The first references were mostly tables. They included familiar status treatments: pills in rows, dedicated status columns, and labels for work in progress. Those were useful examples, but CRRT’s interface used cards, so I still needed to understand how the same information could work inside a different layout.

I asked Grok Bot to look again, specifically for cards using statuses. That second pass gave me something more relevant to react to. I liked the placement in the Featurebase reference, where the status pill sat toward the top of the card.

From there, I had two directions I wanted to see: a pill above the title, and a layout with the title followed by progress before the description. Those are small changes on paper, but they change what someone encounters first when scanning a dashboard.

This is an easy place to be too vague with an AI design agent. If the references keep missing the mark, describe the structure you need: cards, rows, a detail panel, or a board. Then explain what the reference needs to help you decide.

Explore card UI design in Paper

I asked Grok Bot to create the concepts on another page in the same Paper project and to use our existing Storybook components. I also asked for additional ideas based on what it knew about the repository and the product. I wanted a few alternatives that would help me think through the interaction.

One suggestion put the agent’s name into the status treatment. Another explored a four-part progress indicator. Seeing these options together made me reconsider how much information the card should show.

I liked aspects of the progress indicator, and the agent label was interesting. But I was unsure whether users actually cared which agent was doing the work. That question stayed open; an appealing mockup could not answer it for me.

The direction I wanted to pursue combined clearer status placement with actions such as “Mark ready” and “Reject.” I asked to see it in the full dashboard so I could judge the density, hierarchy, and spacing in context.

Bring Storybook components into the design-to-code workflow

Existing components gave the redesign a practical foundation. Our Storybook already documented the interface pieces we were using, so I repeatedly asked Grok Bot to reference them as it explored the cards and implemented the selected direction.

Storybook lets teams develop and inspect UI components and their states in isolation. For this workflow, that made it a useful reference for the building blocks already available in the product. Storybook’s documentation describes how stories capture component states and support UI development.

The first full-screen exploration still drifted from the existing dashboard. I also wanted to adjust the spacing. Having the design in Paper let me inspect those details and make changes before asking for the implementation.

My next instruction pointed to the specific card design I liked and asked Grok Bot to build it into the current dashboard, using the correct components, spacing, and alignment. The card then appeared in the actual product interface. That was the concrete result of the test; creating and reviewing a pull request was still a next step.

How to try this workflow on your own product

Start with one existing interface and one clear problem. If you want the setup instructions and copyable prompts beside you, open the free guide as you work through these steps. The sequence I would repeat is:

1. Describe the confusion. Explain what people cannot understand or do easily. Include the current screen and the labels or interactions you want to reconsider.
2. Find references for the same UI pattern. Ask for examples that match your layout, then explain which details seem useful and why.
3. Request distinct concepts. Compare a few specific choices, such as status placement, progress detail, or action visibility. Ask the agent to explain the tradeoffs.
4. Review the direction in the full screen. Check how the card works alongside navigation, filters, neighboring items, and realistic content.
5. Implement with the existing components. Point to the selected design and the component library, then review the working result before preparing a pull request.

Here is an adapted prompt you can use for the exploration stage:

I want to make the status and next action clearer on these feedback cards. Find card-based references, then create two concepts in Paper using our existing Storybook components. Show one with the status above the title and one with progress below the title. Include a way to move the item forward from the card, and explain the tradeoffs.

For implementation, be equally specific about the target:

Use this selected card concept in the existing dashboard. Reuse the components documented in our Storybook and match the product’s spacing and alignment. Show the result in the full dashboard so I can review it.

These prompts are starting points. In my test, the useful decisions came from reacting to each version and narrowing the next request.

What worked, and what still needed review

Screenshots in the conversation were a surprisingly valuable part of the experience. Grok Bot showed me what it was working on, which made it easier to respond without opening another tool for every update. It felt closer to the way I would share a design with someone and ask for feedback.

The back-and-forth also felt fast, and connecting the tools felt approachable. Those are impressions from this task; I did not run a timed comparison against other agents. I still had to redirect the references, question the information being added, and check the spacing and fidelity to the existing product.

Could a PM or founder try this? I can see this opening up more room for them to explore a product idea and bring something tangible to the team. My test was designer-led, with an existing repository and component library, so those starting conditions matter.

Does it remove the need for design judgment? I was making decisions throughout: which references fit, whether an agent name mattered, where the status belonged, and how much the card should ask someone to read. The agent made it easier to see those choices in a working interface.

I also had no usability results yet. The redesign gave me a direction to test, with open questions about the progress indicator and the clarity of the actions. I would want to watch someone use it and review the implementation before treating the work as finished.

That is what makes me interested in using this process again. I can take a specific point of confusion, explore a few ways through it, and get far enough into the real product to have a much better conversation about what should happen next.

Build your first Grok Bot design workflow

Pick one screen you want to improve and follow our free guide alongside it. You’ll get eight steps for setting up your Bot, connecting your tools, exploring designs, and preparing the chosen direction for implementation, plus copyable prompts and checklists to keep you moving.

You can start with screenshots or a product URL. Connect your repository when you’re ready to work with the code.

Get the free Grok Bot design guide →

Enter your name and email to access the interactive guide.

Related reading

• Paper AI design tool: A code-connected workflow from design to production
• Using Mobbin MCP for design inspiration
• Building a component library AI agents can use