A Pricing Table, Tabs and a Slider From One Prompt Each: How to Ask
Sagar Patel
To generate a pricing table with AI, give the tool the plan names, prices, billing toggle, feature list per plan, which plan is highlighted, button text, and the mobile layout. Missing any of those makes the model invent them. The same rule applies to tabs and sliders: specify content, behaviour, default state and keyboard use.
This post gives you three prompts you can paste into an AI section tool such as Composer. I have not captured outputs for these exact prompts, so I show the briefs, not results. For ideas on what else is worth building, see custom sections a page builder cannot do.
Why Section Prompts Usually Fail
A short prompt like “make a pricing table” asks the model to decide everything. It picks the number of plans, the prices, the features and the style. You then spend time deleting its guesses.
It is worse for behaviour. A tabs block has a default open tab, keyboard rules and a mobile layout. If you do not state them, you get whatever the model assumes, and it may not match your site.
Two habits fix most of it. State the content exactly, and state what must not be added. The same logic drives AI website prompts that get the sitemap you want, just at page scale instead of section scale.
The Pricing Table Prompt
Replace the brackets with your real numbers. Never let the model make up a price.
Build a pricing section with [3] plans.
Plans (use exactly this content):
1. [Name] - [price] per [month] - [one-line description]
Features: [feature], [feature], [feature]
Button: [text] -> [url]
2. [Name] - [price] ... (highlight this plan with a "Most popular" label)
3. [Name] - [price] ...
Billing toggle: [Monthly / Annual], default [Monthly].
Annual prices: [price], [price], [price].
Design: use my global colours and fonts. Highlighted plan has a
stronger border. Equal card heights.
Mobile: cards stack, highlighted plan first.
Accessibility: toggle is a real button group, keyboard operable,
state announced to screen readers.
Do not add plans, features, badges or text I did not list.The toggle is the part that needs code. A static table needs none, which is a good reason to ask first whether you need a toggle at all. Our own price list, for what it is worth, shows monthly and annual numbers on the pricing explained page, so you can see a real toggle case.
The Tabs Prompt
Build a tabs section with [4] tabs.
Tab labels: [A], [B], [C], [D]
Tab content: [exact text and images per tab]
Default open tab: [first].
Behaviour:
- Click or keyboard selects a tab (left/right arrows move
between tabs, Home and End jump to first and last).
- Only the active panel is visible; others hidden from
screen readers.
- The URL hash updates so a tab can be linked directly: [yes/no].
Mobile: tabs become [a horizontal scroll row / an accordion].
Do not add icons or animation unless I list them.The keyboard line looks fussy, but it is the difference between an accessible tabs block and a decorative one. If the tool ignores it, you will catch it in the review step below.
The Slider Prompt
Sliders are the riskiest of the three, because autoplay and touch handling cause most complaints.
Build a slider for [testimonials / products / logos].
Slides: [number], each with [image, heading, text, link].
Visible at once: [3] on desktop, [2] on tablet, [1] on mobile.
Behaviour:
- Previous and Next buttons with visible focus states.
- Swipe on touch.
- Autoplay: [off]. If on, pause on hover, focus and when
prefers-reduced-motion is set.
- Dots show position and are clickable.
Performance: lazy-load images after the first slide;
set width and height to avoid layout shift.
No external slider library unless I name one.Autoplay off is my default. Most visitors never see slide four, and moving content is a common accessibility complaint. If you want it, ask for the pause rules above.
The Two-Round Fix Loop
Expect to iterate. A reliable pattern:
- Round one: the full template above. Read what came back against your content list.
- Round two: one message with every fix, written as a list. Do not trickle changes in one at a time, because each change can disturb the last.
After round two, switch to the visual editor for small tweaks like spacing and colour, which is the workflow in Claude to Elementor: make your website editable with Composer. Prompting is slower than dragging a slider for those. The AI-generated site equivalent of this habit is in what AI gets wrong when it builds a website.
Write the Content Before You Prompt
The prompt is the easy part. The slow part is knowing what goes in it. Before you open any tool, fill a plain list for each section. This takes ten minutes and saves the most time of anything in this post.
For a pricing table, write down:
- Each plan name, exactly as it appears elsewhere on your site.
- Each price and its billing period. If you offer annual pricing, write both numbers.
- The three to six features that actually differ between plans. Do not list ten rows where eight are identical.
- The one plan you want people to pick, and why.
- The button text and where each button goes.
For tabs, write the label and content for every tab, and decide which tab opens first. For a slider, decide how many slides there are and what is in each. If you cannot fill the list, the problem is not the prompt. The section is not ready to build.
One more habit: keep the content in a document, not only in the chat. When the tool returns something wrong, you can point back to the source of truth.
That matters most for prices, because a wrong price on a live page is a real business problem. A model has no way to know your prices, so it will either ask or guess. Treat a guessed number as a bug every time.
Finally, decide what success looks like before you generate anything. “A visitor can compare three plans and click one on a phone” is a testable sentence. “Looks nice” is not. Use the testable sentence when you review the first draft, and you will know quickly whether to keep iterating or change the brief.
What to Check Before You Keep It
| Section | Check |
|---|---|
| Pricing table | Every price and feature matches your list; toggle works by keyboard; no invented plans |
| Tabs | Arrow keys move focus; inactive panels are hidden; mobile layout is usable |
| Slider | Buttons reachable; no autoplay surprises; images have dimensions |
| All three | Looks right at narrow width; no console errors; page speed re-tested |
The deeper checklist is in keeping AI-written code clean. For a wider view of Elementor’s built-in AI and what it leaves out, Elementor AI is a useful comparison, and the Composer docs explain how the editor handles the code afterwards.
A Worked Example of the Round-Two Message
Here is what a good second message looks like. Suppose round one gave you a pricing section with the right plans but a wrong highlight, a missing toggle state and cards of uneven height. The example values below are placeholders, so swap in your own.
Round two fixes, apply all of them in one pass:
1. Highlight the [middle] plan, not the first one.
2. Billing toggle: default to [Monthly]. The active option
needs a visible selected state and aria-pressed.
3. Make all three cards the same height. Buttons align at
the bottom of each card.
4. Remove the "Best value" badge. I did not list it.
5. On mobile, put the highlighted plan first.
Change nothing else.Notice the last line. Without it, a model often “improves” things you were happy with. Each numbered item is one testable change, so you can check them off against the new output in a minute.
If round two still misses an item, do not write a longer essay. Quote the single failing item back and ask for only that. Long corrections invite new side effects.
Common Mistakes and Their Fixes
Most failed section prompts repeat the same few errors. This table lists the ones I see most, with the fix you can apply in the next message.
| Symptom | Likely cause in the prompt | Fix to send |
|---|---|---|
| Extra plans or features appear | No “do not add” line | “Use only the content listed. Do not add plans, features or badges.” |
| Prices look right but the annual numbers are wrong | Annual prices were not supplied | List both monthly and annual price for every plan |
| Tabs work with a mouse only | Keyboard behaviour was not stated | Add the arrow, Home and End key rules from the tabs template |
| Slider moves on its own | Autoplay was not set to off | “Autoplay off. No automatic movement.” |
| Layout jumps while loading | No image dimensions or reserved space | “Set width and height on every image.” |
| Colours and fonts do not match the site | Brand was not mentioned | “Use my global colours and fonts, no new font families.” |
Each fix is a sentence you can keep in a notes file and paste in. Over a few projects, those sentences become your own house style for prompts.
Pricing Table, Tabs or Slider: Which Fits the Job
Sometimes the best prompt is the one you skip. Before you generate anything, check whether the component earns its place. The table below gives my rule of thumb.
| If you have | Use | Why |
|---|---|---|
| Two to four plans to compare side by side | Pricing table | Visitors compare columns, so keep them visible together |
| Four or more related topics, each with a few paragraphs | Tabs | Saves vertical space and keeps related content grouped |
| One topic with a long list of short items | Accordion or plain list | Tabs hide content that people need to scan |
| Several testimonials or logos | Slider, or a static grid | A grid shows everything at once and avoids autoplay problems |
| Content that search engines should read and visitors must find | Plain headings and text | Hidden panels are easier to miss |
If the answer is a plain grid or list, you may not need a prompt of this length at all. For an agency view of when a custom build earns its cost, see Composer vs custom HTML widgets and code snippets.
When the component does include behaviour, write it as a spec first. The interaction spec template for designers covers the same ground for any custom behaviour, and the performance test log is a good last check before you publish.
One more point on reuse. Once a template works for your site, save the filled-in version, not only the blank one. Next time a client needs a similar section, you start from a prompt that already carries your brand lines, your accessibility lines and your “do not add” line, and you only swap the content.
That saved prompt is also a useful thing to share with teammates. It means every section on a project follows the same rules, even when different people write the prompts.
FAQ
Can AI build a pricing table in WordPress?
Yes, if you give it exact plan names, prices, features and behaviour. It writes markup and styling quickly. The risk is invented content, so supply every number yourself and ask it not to add anything. Always compare the result with your price list before publishing.
How detailed should a pricing table prompt be?
Detailed enough that no content decision is left to the model. List each plan, price, feature and button label, state the highlighted plan, the billing toggle and the mobile layout. A short prompt works for a throwaway draft, not for a page customers read.
Should I use a slider at all?
Only when space forces it. Many visitors skip later slides, and autoplay can annoy or exclude people. A static row of cards or a grid often performs better. If you do use one, keep autoplay off and test touch and keyboard use.
Why ask for keyboard behaviour in a prompt?
Because models often skip it unless told. Tabs and sliders are interactive controls, and keyboard users need to reach and operate them. Stating arrow-key behaviour and visible focus in the brief gets a better first draft and an easier review.
Are these prompts tested?
I have not captured outputs for these exact prompts, so I do not show results. They apply the same brief structure that works for any section: exact content, exact behaviour, explicit limits. Run each once and review it with the table above.
When you want to run these on a real page, you can Get Started and paste the first template into a staging project.
Every feature named in this post is listed by product: all UiChemy features, AI to WordPress features.
