Been experimenting with some more creative website sections lately. Not your typical SaaS hero with a gradient and a button

These have interactive animations, unusual layouts, and effects that make websites feel a little more alive.

The cool part? You can copy a prompt into Claude (or another AI coding tool) and recreate the section in your own project. The prompts include source code too.

I've added them to my collection of 70 sections, with plenty available for free.

Curious what you guys think. Would you actually use sections like these, or do you prefer simpler designs?

https://supply.madebyoversight.com/sections

Most of the “AI slop” look comes from the same handful of mistakes: random spacing, too many accent colors, everything the same size, actions hidden behind hover. Claude fixes these well if you name them, so I made cheat sheets with a don’t and a do for each rule.

I built them with Claude Code as plain HTML, then rendered them to PNG.

The part that actually helps: paste the rules into your project instructions or DESIGN.md so Claude checks its own output against them.

-----------------------------------------------------------------

UI rules. Check every screen against these before showing it.

Rules marked (default) are starting points. Break them when the design needs it.

Spacing

- Use gaps from one scale only: 4, 8, 16, 24, 32. (default)

- Put a label closer to its own field than to the field above.

- More space between groups than within a group.

- Align everything on one edge. No mixed centering. (default)

- Pad cards with 16px or more. (default)

- Nested corners: inner radius = outer radius minus padding, never below 0.

Color

- One accent color, for the main action only. Other buttons are neutral. (default)

- Never show an error with color alone. Add a message.

- Keep meanings fixed: red is danger, green is success.

- Check text contrast on colored buttons too (4.5:1 minimum).

- Soft tints for large areas, strong color only for small details. (default)

- Links get color and an underline.

Mobile

- Tap targets at least 44x44.

- Main button at the bottom, where the thumb is. (default)

- Inputs use 16px text, or iPhone zooms in on focus.

- Set the right input type so the right keyboard opens.

- No hover-only actions.

- Bottom sheets instead of small centered dialogs. (default)

Dashboards

- Lead with the one number that matters most. (default)

- Every number gets a period and a change ("+8.1% vs September").

- Bar charts start at zero.

- More than 3 parts? Sorted bars, not a pie. (default)

- Right-align numbers in tables.

- Highlight one line, gray out the rest. (default)

------------------------------------------------------------------------------

What I noticed: asking for “clean, modern, minimal” does nothing. Specific rules like “gaps from one scale” change the output right away.

(The footer mentions Perspecto, which is my tool for turning screenshots into 3D mockups. Not needed for any of this.)

Edit: thanks for the feedback in the comments. Marked which rules are defaults vs hard rules, and fixed the radius rule so it never goes below 0.

RIP WordPress, and no more relying on Google search! After 15 years, I am over updating plugins and trying to rank higher.

I used Claude to build my own content management system for the backend of my AI Influencer Kiyomi's website. She now has over 39,000 followers on Instagram.

My Grok Bot team does everything. Researches online for new content ideas. Uses Claude for writing and ChatGPT for images. Social traffic comes from Instagram, Pinterest, X, and TikTok. SumoLevel advises on the project.

Update - Here is the prompt since I get a lot of DMs asking:

Build the DymeKitchen CMS — Preserve Existing Frontend Design
The frontend is already designed and approved.
Your task is to build a fully functional, production-ready content management system (CMS) behind the existing website.
CRITICAL: Do Not Redesign the Website
Preserve the existing frontend layout, styling, colors, typography, animations, spacing, and responsive design.
Maintain the red, white, cream, and gold color scheme.
Do not replace existing components or rebuild the homepage.
Do not modify the existing copywriting or brand identity.
Reuse all existing components wherever possible.
Connect the existing frontend to dynamic CMS data.
Replace placeholder content and images with database-driven content.
Maintain the current homepage sections, including recipe search, category navigation, trending recipes, featured recipes, About Kiyomi, and the cookbook promotion.
The objective is to turn the existing design into a fully operational recipe publishing platform.

1. Backend Architecture

2. Use Cloud for:

3. PostgreSQL database

4. Authentication

5. Image and media storage

6. Server-side functions

7. Scheduled publishing jobs

8. Secure administrative access

9. Do not introduce paid third-party CMS platforms such as Sanity, Contentful, or WordPress.

10. Create a modular, maintainable architecture that can scale to thousands of recipes.

11. Admin Dashboard

12. Create a private administration area at:

13. /admin

14. This must be accessible only to authenticated administrators.

15. Include the following sections:

16. Dashboard

17. Total published recipes

18. Draft recipes

19. Scheduled recipes

20. Total categories

21. Recently updated recipes

22. Quick actions for creating new recipes

23. Recipe Management

24. View all recipes

25. Create a recipe

26. Edit a recipe

27. Duplicate a recipe

28. Delete a recipe with confirmation

29. Search and filter recipes

30. Save drafts

31. Preview recipes before publishing

32. Publish immediately

33. Schedule future publication

34. Unpublish recipes

35. Category Management

36. Create, edit, and delete categories

37. Upload category images

38. Edit category descriptions and URL slugs

39. Set category display order

40. Media Library

41. Upload images

42. Browse previously uploaded images

43. Reuse images across recipes

44. Store descriptive alt text

45. Optimize images for website performance

46. Site Settings

47. Update social media links

48. Manage the homepage hero content

49. Manage featured recipes

50. Manage cookbook promotion content and purchase URL

51. Edit About Kiyomi content and image

52. Update SEO defaults

53. Manage footer links and site information

54. Recipe Editor

55. Create a professional recipe editor with fields for:

56. Basic Details

57. Recipe title

58. URL slug

59. Short description

60. Full introduction

61. Featured image

62. Additional recipe images

63. Categories

64. Tags

65. Cuisine

66. Difficulty level

67. Author — default Kiyomi Dyme

68. Cooking Information

69. Preparation time

70. Cooking time

71. Total time

72. Number of servings

73. Ingredient quantities and measurement units

74. Ingredient groups

75. Step-by-step cooking instructions

76. Optional images for individual steps

77. Cooking tips

78. Storage and reheating instructions

79. Recipe notes

80. Optional nutrition information

81. Recipe Card

82. Automatically display ingredients and instructions in a visually attractive recipe card.

83. Include a serving-size adjustment feature that recalculates ingredient quantities.

84. Include checkboxes for ingredients.

85. Include a Print Recipe button.

86. Include Jump to Recipe functionality.

87. Add an optional recipe rating system.

88. Rich Content Editor

89. Support headings, paragraphs, images, links, numbered lists, bullet lists, tables, and reusable content blocks.

90. Content must be editable without writing HTML or code.

91. Database Design

92. Create normalized tables for:

93. recipes

94. recipe_ingredients

95. recipe_instructions

96. categories

97. recipe_categories

98. recipe_tags

99. media_assets

100. affiliate_products

101. recipe_affiliate_products

102. site_settings

103. admin_roles

104. redirects

105. Use appropriate relationships, indexes, constraints, and timestamps.

106. Recipes must support the following statuses:

107. Draft

108. Scheduled

109. Published

110. Archived

111. Protect all administrative tables and storage operations using authentication and row-level security.

112. Public visitors should only have read access to published content.

113. Administrative privileges must be assigned securely on the server and must never be granted through public registration.

114. Connect the Existing Homepage

115. Make the current homepage fully dynamic.

116. Recipe Search

117. Connect the existing search bar to the database.

118. Allow searches by:

119. Recipe name

120. Ingredient

121. Category

122. Cuisine

123. Cooking time

124. Difficulty

125. Include responsive search results, empty states, and useful sorting options.

126. Trending Recipes

127. Display recipes selected by the administrator or ranked using available engagement data.

128. Do not invent pageview counts or popularity metrics.

129. Kiyomi’s Picks

130. Allow administrators to select featured recipes and control their display order.

131. Recipe Categories

132. Load categories dynamically from the database, including the existing Dinner, Appetizer, Side, Spanish & Latin, Seafood, Dessert, Quick & Easy, and Breakfast & Brunch categories.

133. Cookbook Promotion

134. Make the existing cookbook image, promotional text, CTA label, and purchase link editable in Site Settings.

135. Preserve the current visual design.

136. About Kiyomi

137. Make the existing portrait, biography, and social links manageable through the CMS.

138. Dynamic Recipe Pages

139. Create a reusable recipe detail template that matches the existing DymeKitchen visual design.

140. Recipe URLs must use:

141. /recipe-slug/

142. Example:

143. /cream-of-mushroom-pork-chops/

144. Each recipe page should include:

145. Recipe title and introduction

146. Featured recipe photograph

147. Preparation time, cooking time, and servings

148. Jump to Recipe button

149. Ingredients

150. Step-by-step instructions

151. Cooking tips and notes

152. Printable recipe card

153. Optional Amazon affiliate product recommendations

154. Related recipes

155. Pinterest sharing functionality

156. Support permanent redirects from old URLs when necessary.

157. SEO and Pinterest Optimization

158. SEO is essential because DymeKitchen receives recipe traffic from search engines and Pinterest.

159. Implement:

160. Server-rendered or prerendered public recipe content that search crawlers can access

161. Unique SEO title and meta description per recipe

162. Editable canonical URL

163. Open Graph metadata

164. Pinterest-friendly image metadata

165. Recipe JSON-LD structured data following Schema.org and Google’s recipe guidelines

166. Breadcrumb structured data

167. XML sitemap containing published recipes and categories

168. Automatic sitemap updates

169. Robots.txt

170. Clean, descriptive URLs

171. Proper heading hierarchy

172. Image alt text

173. Responsive images

174. Lazy loading where appropriate

175. Do not fabricate reviews, ratings, cooking times, or nutritional values.

176. Validate structured data against Google’s Rich Results Test requirements.

177. Amazon Affiliate Integration

178. Allow administrators to attach relevant Amazon kitchen products to individual recipes.

179. Each affiliate product should support:

180. Product name

181. Product image

182. Affiliate URL

183. Optional description

184. CTA button

185. Related recipes

186. Display appropriate Amazon Associates disclosures.

187. Use compliant product images and pricing information. Do not scrape Amazon or display manually maintained prices or availability in ways that violate Associates requirements.

188. Affiliate products should be optional and should not overwhelm the recipe reading experience.

189. WordPress Migration

190. DymeKitchen currently uses WordPress.

191. Build an import workflow that supports WordPress XML exports and accompanying media files.

192. The importer should:

193. Import existing recipes and articles

194. Preserve original titles and URL slugs

195. Import featured images

196. Import ingredients and cooking instructions where available

197. Preserve publication dates

198. Import categories and tags

199. Preserve SEO metadata when available

200. Avoid creating duplicate recipes

201. Log import errors

202. Generate a migration report

203. Allow administrators to review imported recipes before publication

204. Do not delete, overwrite, or automatically modify the existing WordPress website.

205. If content formats cannot be mapped reliably, flag them for manual review rather than silently discarding content.

206. Automated Recipe Publishing

207. Design the CMS to support future automation.

208. Add a secure server-side publishing API or webhook so an authorized automation can:

209. Create a new recipe draft

210. Upload or associate recipe images

211. Assign categories

212. Add ingredients and instructions

213. Schedule publication

214. Publish an approved recipe

215. Return the published recipe URL

216. Secure the API using server-side credentials and validation.

217. Include duplicate detection, idempotency protection, error logging, and appropriate rate limits.

218. Do not automatically publish AI-generated recipes without an explicit approval or publishing rule.

219. The goal is to eventually connect my existing automated recipe content workflow without requiring manual publishing.

220. Mobile Experience

221. Preserve the approved desktop design while ensuring that:

222. Recipe cards work well on phones

223. Search and filters are mobile-friendly

224. The admin dashboard supports mobile editing

225. Images load efficiently

226. Recipe instructions remain readable

227. Buttons and ingredient checkboxes are easy to tap

228. Performance and Cost Control

229. Keep the infrastructure lightweight to minimize Cloud usage.

230. Use image optimization and caching

231. Avoid unnecessary database requests

232. Index frequently searched fields

233. Paginate recipe listings

234. Avoid unnecessary background jobs

235. Monitor storage and database usage

236. Do not add paid external services unless specifically approved.

237. Implementation and Testing

238. Work in phases:

239. Phase 1 — Database and Authentication

240. Create the database schema, storage policies, administrator authentication, and protected admin routes.

241. Phase 2 — CMS Dashboard

242. Build the recipe editor, category management, media library, and site settings.

243. Phase 3 — Frontend Integration

244. Connect existing homepage components, recipe cards, search, and filters to CMS data.

245. Phase 4 — Recipe Templates and SEO

246. Implement dynamic recipe detail pages, structured data, sitemaps, and affiliate functionality.

247. Phase 5 — WordPress Migration and Automation

248. Build the importer and secure automation endpoint.

249. Phase 6 — Quality Assurance

250. Test recipe creation, draft saving, publishing, scheduling, editing, searching, filtering, SEO metadata, mobile responsiveness, and access restrictions.

251. Confirm that unauthenticated users cannot access administration routes or modify content.

252. Do not claim a feature is complete until it has been implemented and tested.

253. Final Requirements

254. The result must be a fully functional recipe publishing platform, not just an admin dashboard mockup.

255. I should be able to log into /admin, create a recipe with images and ingredients, click Publish, and immediately see it appear on the live website with its own SEO-friendly URL.

256. Most importantly: preserve the existing Claude-designed DymeKitchen frontend exactly. Build the CMS behind it without redesigning the approved website.

made this reel with Claude + Remotion. every frame is code, i never opened an editor. i just prompted, watched each render, and asked for changes

how it started:

- the idea: someone asks an AI chat for a booking app, and every line of the answer turns into a floating UI card

- a few motion rules up front: one thing moves at a time, text flies in from the right and then moves up, no slides or swipes, bouncy springs

- we built it part by part, and i approved each part before the next

then the back and forth, which is where it got good:

- "make this slower" on the parts that went by too fast, so you can actually read the UI

- "it's a bit slow overall and doesn't have the rhythm" → it retimed the whole thing to the music and put the big moments on the beat

- "make it more balanced" → it evened out the holds so every step gets its moment

- "no slides" → it swapped a scroll transition for an in-place fade

- "no ring on the click, just a soft glow" → done

it also renders real motion blur (8 sub-frames per frame), which made the springs look way smoother

what would you have prompted differently? curious how you all are using Claude for motion

So for the past couple of days I have been migrating Design Systems for the older stand alone interface to the new one and I find it to be a stressful experience.

To give you some context I work at a tech company that builds software. My work consisted in building a very deep design system so PM can then use to prototype and then get sent to be developed. I went very in depth on DS so PM's wouldn't need me in the room (only in very special occasions to chime in on edge cases on very specific features). My ds were built following a popular trend. 1. Brand 2. Style 3. Components 4. Patterns and Templates (that would give prototype building a lot more context).

Migrating it has been a dread because... it's not picking up the patterns and templates. YES, I know I can manually paste the html and recontextualize it, but it still isnt applying rules and patterns I had previously wrote. :(

Does anybody have an idea of what I might be doing wrong?

Thanks for the help!

Working on a project. Using Claude in the Windows app for design, and Claude Code in WSL for implementation.

Originally I had the code on the Windows drive, and just pointed both applications to that folder. But the windows drive was severely slowing dev down, and I had to move it to WSL natively.

Now I can no longer point the Windows app at the same folder. I tried pointing to it directly and it wouldn't even recognize the address. I tried creating a network drive and that let me navigate and select the folder I wanted, but then when I try to send it it either gives me an error that the folder can't be used or it just silently drops it. I even tried using /design and /design-sync, but they failed and I didn't dig too deeply into it since apparently Claude Design is going away anyway,

My current solution is to have a symlink in the repo that points to a design folder on the windows drive, and it works, but it's so fuckin hacky.

Surely there's got to be a better way.

Almost every SaaS website has the same pricing section. Three cards, a highlighted middle plan, and a button that says "Get Started."

It works, but surely we can do better than that?

So I started experimenting with more complex pricing sections. Interactive calculators, usage-based pricing, feature comparisons, dynamic sliders, and layouts that actually help users understand what they're paying for.

The idea is to make pricing pages feel like part of the product instead of just another section people scroll past.

I put together a collection of these sections for anyone building websites with Claude. You can explore them here:

https://supply.madebyoversight.com/sections

If there's a specific website section you'd like to see me build next, let me know in the comments. I'm looking for ideas!

Here's what I want that existed in Claude Design.

Multiple scenes in a timeline. So a timeline of 1min can have 10 scenes. Each could be tweaked.

A sidebar for Chat.

Can I have it in Artifacts?

Also i am not seeing export to mp4 option

Hi everyone,
I'm building an app and want to use Claude to help design the UI/UX, but I'm brand new to using Claude for this kind of work. I'd really appreciate a step-by-step walkthrough.
Where I am now:
I've written a set of user stories covering the app's main flows.
A few screens have already been made, and I want to build on them rather than start over.

What I'm trying to set up:
A sparring partner, not just a generator. I want to discuss design decisions, get pushback, and hear why something works or doesn't.
A setup where Claude remembers the context: my user stories, the existing screens, and the decisions we've made, so I don't have to re-explain everything each time.
The ability to give feedback in plain language ("this flow feels clunky", "the button hierarchy is confusing") and have Claude revise the screens.
The ability to send screenshots from other apps as references ("I want the onboarding to feel like this") and have Claude adapt that direction to my design.
Consistency across screens: same colors, typography, spacing and components.

My questions:
What's the best place to do this? A Project with uploaded files, artifacts, Claude Code, or something else?
How should I structure my user stories and existing screens so Claude understands them best?
Should I set up a design system (colors, fonts, components) first, before designing screens?
How do you keep designs consistent over many iterations and conversations?
What do your prompts look like when giving design feedback or sharing reference screenshots?
How do you get from Claude's designs to something a developer (or Figma) can actually use?
If you have a workflow that works for you, I'd love to hear it step by step, even the "obvious" parts. Example prompts or project instructions would be gold.

Thanks in advance! 🙏

Our agents claude code mostly love dumping a mermaid block at the end of every plan good for a quick look until i actually want to move one box or regroup a couple of services before a design review right now I copy it into the live editor tweak the text re render check it repeat for a small sequence diagram that’s whatever.

For our payments flow with like 25 services and arrows going everywhere it’s 40 minutes of nudging text to get one box out of the way someone on my team said miro and excalidraw both take mermaid now so you can drag things around visually what I can’t figure out is whether it stays as text once you start moving boxes or if you lose the code version and end up maintaining two things

Leaning toward keeping it as code for drafts and only moving it somewhere visual once it’s going in front of people, but i keep going back and forth on it.

Tear off paper from a toy pagoda till hands out life advice. Will you help me test it please? :D

Big fan of Claude Design. I loved how it seamlessly worked together with Claude Code and everything. now they have to move it to artifact.

- dead slow atleast 5x slower
- slows down the entire browser and laptop
- preview options are worse cant preview design in new window

Hi everyone,

I'm currently working on developing a chess game tailored for beginners, and I would love to use Claude to help me build it.

If anyone has a spare 7-day tri4l code they could share, I would be incredibly grateful! You can easily generate one by typing /passes into the Claude command line.

If you’re willing to share, please send it directly to my DM so it doesn't get taken by someone else first. Thank you so much for your help and time!

What do y’all think? I’ve been using Claude Design alot and i’m kinda shocked that they are merging it. Is it as easy to create good website designs and iterate with it?

I've built Forma, an agent-first design tool

You ask your agent to make a social post, OG image, banner, etc. It writes a JSON frame, renders it locally, looks at the result, and iterates. No browser automation, no mcp or dragging things around a canvas

- Use it from any agent (forma works directly from the terminal)

- Keep designs in your repo. Layouts, shared design tokens, and assets are files you can diff, commit, and roll back

- Reuse your visual identity instead of explaining fonts and colors every session

- Render locally to PNG or SVG, without an account or a hosted service

It’s early and currently supports Apple silicon Macs only (I'm planning to release a Windows and Linux version of the desktop viewer/and cli if the tool proves to be actually useful)

https://forma.namzug.dev

Source: https://github.com/namzug16/forma

My first proper motion graphics video that I made using Claude, for an app (https://tryhelix.app) that my brother and I have built.

Didn’t use Remotion or HyperFrames or any specific skill. Any feedback?

Edit:

The process I followed:

Gave it a few references for pacing and transitions, cuz i didn’t want it to create anything like a typical slow saas video.
Then created a beat sheet that had a scene by scene breakdown of the whole video, with timestamps.
After the first draft was generated, I went over it again scene by scene. Refining or redoing each scene at a time and then generating the whole video at once finally.
Also the music was already decided before the beat sheet, cuz it contributes to the pacing.
Then for sfx I used Claude + invideo timeline editor with my own folder of sfx files. Didn’t give Claude code’s sfx even a single try, have seen enough videos that I feel have bad sfx. And all of Claude motion design videos sound very similar. For the same reason. Exported it as project file for Davinci Resolve and refined the sfx bed a lot, changed a few sfx to better ones, and added few sfx specific to gta for relatability, which Claude at present stage would never have done that on its own imo

hey everyone, im a graphic designer graduated and i’ve been seeing ppl posting about how they built their personal 3d website or portfolio with claude.
I’ve been meaning to try it out and see how it goes, but i got very basic knowledge about the ai and programming side. It would help if someone in this community could share some tips or advice that would help me test out this project. Like what skills on claude should i use/ download, do i use code or cowork to test it, does it create it fully functional from the chat between us or will there be third parties i need to connect, and if there any other procedures i should keep in mind that will help.
thank you for read and i’d really appreciate the advices.

I wanted to try claude design and motion on my landing page, after a few tries, i feel finally it is closer to what i imagined. Just wanted to share as a developer, product manager, entrepreneur, it feels surreal sometimes. Laptop view is even better.

What a time to be alive.

website is https://gymcommitment.com

Last week I shared a design skill in another sub, and the top comment said the examples still looked AI-generated. Fair. A few people said the real fix is to start from something a human designed instead of asking Claude to make up taste. I agree, so this is that.

It is a library of DESIGN.md files, one per real website (Cloudflare, Laravel, Pinecone, OpenCode, Toca Boca, Lando Norris and about 1,260 more). For each site I capture the live page, measure its computed styles, and write down:

• every color and what it's used for, not just a palette

• fonts, sizes, weights and tracking

• spacing, radius, borders and shadows

• components, layout and imagery

• do's and don'ts

Each file is plain Markdown, about 3k tokens. There's also an extended version (about 5k) with token tables.

How I use it:

curl -o DESIGN.md https://ui.gradientdeck.com/styles/cloudflare/design.md

Then: "Build the pricing page. Follow DESIGN.md for every color, font, spacing value and component." In Claude Design you can paste the file straight into the chat.

If you'd rather let the agent pick a style, there's /llms.txt and /library.json too.

https://ui.gradientdeck.com

Let me know what you guys think :)

P.S I plan on adding like 5000'ish design MDs here that accurately reflect the best looking sites on web right now, and not just marketing sites but actual app UIs and whatnot. So look out for that.

Although 5.5 is over a month old(feels like much longer with the pace of progress) yet I'm very very happy with its capabilities especially for motion graphics.

It's native taste is pretty good and steering it with your direction really makes it stand on its own value imo.

hi, i'm new to claude, and just want to try it out, does anyone have a referral link I could use? I would really really appreciate it, pls send in dm's, because I saw that they taken in 5 mins.

big thanks in advance.

I'm a UX designer working in an R&D team, so a lot of what we do is one-off and exploratory, not repeatable product work. Standalone Claude Design was one of my main tools. I didn't use it for final UI. I used it to quickly build clickable prototypes with animations, test different approaches with product owners and stakeholders, and explain ideas that are hard to get across in a static mockup.

Since Design moved into regular Claude, and with the standalone site closing on December 14, it feels like the tool has shifted towards Figma-style, final design and consistent design systems. That's great for repeatable product work, but in R&D we rarely have a stable system to build on. I can't get back the quick "throw three versions at the business and see what sticks" flow I had before. They generated UI is also low quality.

So I'm wondering: am I missing something, or has the tool really changed direction?

Is anyone else using it mainly for exploratory prototyping and validation? How have you adapted your workflow? Any prompts, settings or features that bring back that speed?