How do you keep a brand's promise of calm intact once real users start clicking through checkout?

Mudita builds minimalist devices around one idea: technology that harmonizes with your life instead of competing for your attention. The brandbook lays that promise out in detail - tone, restraint, what the brand should never feel like. My job was carrying that same discipline into the product itself.

I worked across the checkout flow, the storefront and category browsing, and the product page above the fold - three surfaces where small frictions had quietly built up against the brand's own case for calm. The brandbook gave the rules. The UI work was making sure those rules survived contact with a real cart and a real user.

For the case study visuals, I used AI for the first time to produce product footage 🤖 - wind moving through a scene, an object drifting in place. Higgsfield was genuinely a good way to learn that workflow fast.

Full case study - actual before/after breakdowns - is up on Behance 🔗, linked below.

Genuinely curious where people land on this: generating production assets with AI is fast, and honestly kind of fun as a workflow - but there's real pushback that it's taking work away from people who used to shoot this stuff. Where do you fall on that?

The checkout flow detail is what stands out to me, that's usually where a brand's calm promise turns into three different button behaviors fighting each other. On your AI question, I think it matters less whether it's fast and more who's checking the output against the brand's...

𝗢𝗻𝗲 𝗼𝗳 𝗠𝘆 𝗙𝗮𝘃𝗼𝗿𝗶𝘁𝗲 𝗣𝗮𝗿𝘁𝘀 𝗼𝗳 𝗪𝗲𝗯 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗜𝘀𝗻'𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁. It's figuring out what's wrong. A client might say: “Our website isn't working.” That's not really a problem statement. It's a symptom. So I start digging. Is the messaging unclear? Is the user journey confusing? Is the mobile experience poor? Is the website slow? Are forms failing? Is traffic reaching the wrong pages? Is SEO holding the site back? Is the technology itself limiting what the business wants to do? Sometimes the answer is technical. Sometimes it's strategic. Sometimes it's both. That's why I enjoy website projects that require more than simply following a checklist. There's something satisfying about taking: “𝗦𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗶𝘀𝗻'𝘁 𝘄𝗼𝗿𝗸𝗶𝗻𝗴.” and turning it into: “𝗛𝗲𝗿𝗲'𝘀 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝘄𝗵𝘆, 𝗮𝗻𝗱 𝗵𝗲𝗿𝗲'𝘀 𝗵𝗼𝘄 𝘄𝗲 𝗳𝗶𝘅 𝗶𝘁.” That's where I believe real development value lives.

Turning a vague complaint into something both sides can see is where these projects get easier. I like to write one testable sentence first: mobile visitors reach the form but leave before submitting. Then I talk about fixes.