Skip to content

Making you hungry before you reach the bottom of the page

Designing and building Beikit Bakery’s website. Research to deploy, no development team.

Role

Product Designer

Scope

End-to-end

Timeline

6 weeks

Stack

Figma, Claude, Claude Code, Lovable, Vercel

The challenge

A bakery opening in six weeks that only existed on social media

Beikit is an American-style bakery in Granollers. No site of its own, no reputation, nothing but the feed. And a deadline tied to a lease and an opening party, so it couldn’t move.

I did all of it: research, architecture, bilingual copy, legal compliance, high-fidelity design for desktop and mobile, and the build itself, from a .md brief to a live site with Claude Code.

~25%

The founders report an increase in online orders in the weeks after launch.

The brand system already existed: logo, palette, typography, illustrations. My work starts where that ends, at how a brand becomes a product.

The research

Nobody wanted to browse. They wanted to order.

Two sessions with Juan and Anna, goals first and brand personality second. Then five interviews with regulars of Twin Bros, their burger restaurant in the same city and the closest proxy audience available before Beikit opened.

What surfaced

  • 01

    Local bakery sites were hard to navigate and didn’t read as trustworthy. The bar was low.

  • 02

    People didn’t want to get lost in a catalog. They wanted the shortest path to ordering.

  • 03

    A new brand borrows no reputation. Trust had to come from the food and from proof that other people already buy there.

  • 04

    Catering leads die from slow replies and long forms. That’s what people cited for giving up on competitors.

  • 05

    Almost all traffic would be mobile, and nobody had checked whether a long page works on a phone.

The problem, defined from the user

Primary: the local customer

Who
Someone discovering Beikit from Instagram, on their phone
Needs
to reach the menu and an order in seconds, without scrolling the whole page
Because
they don’t know the brand yet, and judge whether it’s worth their time before spending any scroll on it.

Secondary: the catering client

Who
Someone organizing a company event in the Vallès Oriental
Needs
to see at a glance what they can order and know when they’ll get a reply
Because
they abandon any supplier that asks for a long form with no guarantee of a reply.

Underneath both: nobody arrives at a new bakery’s site with patience or with prior trust. Both have to be won in the first few seconds, and not with brand content, but by removing steps and showing that other people already buy there.

Every insight produced a decision

Local competitors are generic and hard to navigate

A single scrolling page, food-first, on a five-layer visual system pulled from the brand’s own Instagram

New brand, zero existing trust

“Bestseller” badges, and the live Google rating directly under the CTAs

They want to order fast, not browse

Two-tier hero CTA: “Pide ahora” / “Ver carta”. Three explicit ordering paths

Catering dies in long forms

An 8-field form, real-time validation, and a visible 48-hour response commitment

Mobile traffic plus a long page means people who never reach the CTA

A persistent bottom navigation bar on mobile

Constraints

What couldn’t move

  • The date

    Tied to the physical opening, not to a sprint.

  • No developer

    I was the only person who could take this from Figma to a production URL.

  • Real legal exposure

    RGPD/LOPDGDD non-compliance in Spain carries fines from €3,000 to €300,000.

  • The business model changed mid-project

    The founders wanted their own checkout. They signed a delivery partnership instead, and the requirement disappeared.

  • Mobile-first usage, desktop-first review

    Traffic would be mobile, but the founders reviewed on a large screen. That mismatch drove the most important decision in the project.

Launching a few weeks late would have cost the business almost nothing: a few more weeks without an online presence. What it would have cost was my own standard. Juan and Anna set that date, and a deadline I agree to with a stakeholder isn’t negotiable for me, whether or not missing it shows.

The decisions

Five decisions to make a screen feel edible

Beikit sells something you can’t smell or taste through a screen. The entire interface exists to compensate.

What the interface is built on

  • Cut outWith backgroundCut out

    The photo doesn’t illustrate, it converts

    Images of desirable food produce measurable neural and physiological responses. Which is why every product shot is cut out: with no background competing, there is nothing else to look at.

    Spence et al., Brain and Cognition, 2016

  • Sweet, Sour, Roasted, NeutralSweetSourRoastedNeutral

    Colour sets the flavour expectation

    Colour and basic taste associate consistently: red and pink with sweet, brown with roasted. Beikit’s palette lives entirely in that register.

  • Sweet / BitterSweetBitter

    Curves taste sweet

    Rounded forms read as sweet, angular ones as bitter. The system is obsessively curved: squircle radius, waves, a sun-shaped isotype, script type. The one angular element is the starburst, reserved for novelty and never used on product.

  • BestsellerBestseller

    Aesthetics substitute for reputation

    An attractive interface reads as more trustworthy, and that perception transfers to the product. The von Restorff effect is why the “Bestseller” badge works: it is scarce.

On that foundation

The Beikit hero: two buttons side by side, Pide ahora and Ver carta, with the Google rating on the line below.
01

Hero CTA hierarchy

“Pide ahora” primary, “Ver carta” secondary, while catering doesn’t exist as a destination yet. The Google rating sits directly beneath: social proof at the decision point, not buried in a footer.

02

Cards that sell appetite, not information

On hover the photo scales up and the whole card takes the product’s colour: a cookie goes brown, a matcha cheesecake goes green. Not decoration. It sets a flavour expectation before the user reads a word.

03

Three cards per category, not nine

Building the catalog made it obvious it was too long. Hick’s Law and the choice-overload literature agree: nobody decides better with nine flavours competing before they have picked a category. The default caps at three and expands on demand.

Hick 1952; Iyengar & Lepper, Journal of Personality and Social Psychology, 2000

04

“Bestseller” badges

For a three-week-old bakery with no recognition, a “Bestseller” tag does the job an established brand gets free from word of mouth. It borrows the crowd’s validation before the crowd is visible on the site.

The check I ran with Juan and Anna before shipping: the badge goes only on demonstrably most-ordered items, never on what they want to push that week. That is the line between using social proof and faking it. Category order is their call; the badge and the cap are mine.
05

Symmetric cookie buttons: the pattern I chose not to use

European regulators have spent two years fining banners that gave “Accept” more visual weight than “Reject”. Beikit’s gives both buttons the same size: same padding, same type, and the only difference is a fill.

GDPR Article 7 requires it, and it is consistent: every other persuasive pattern here pushes someone toward what they came to do. A dark pattern in a consent banner would push them away from a decision about their own data.

  1. The Beikit hero: two buttons side by side, Pide ahora and Ver carta, with the Google rating on the line below.
    01

    Hero CTA hierarchy

    “Pide ahora” primary, “Ver carta” secondary, while catering doesn’t exist as a destination yet. The Google rating sits directly beneath: social proof at the decision point, not buried in a footer.

  2. 02

    Cards that sell appetite, not information

    On hover the photo scales up and the whole card takes the product’s colour: a cookie goes brown, a matcha cheesecake goes green. Not decoration. It sets a flavour expectation before the user reads a word.

  3. A menu category showing three product cards and a button to open the rest of the flavours.
    03

    Three cards per category, not nine

    Building the catalog made it obvious it was too long. Hick’s Law and the choice-overload literature agree: nobody decides better with nine flavours competing before they have picked a category. The default caps at three and expands on demand.

    Hick 1952; Iyengar & Lepper, Journal of Personality and Social Psychology, 2000

  4. The same category with every flavour expanded, one of the cards carrying a Bestseller badge.
    04

    “Bestseller” badges

    For a three-week-old bakery with no recognition, a “Bestseller” tag does the job an established brand gets free from word of mouth. It borrows the crowd’s validation before the crowd is visible on the site.

    The check I ran with Juan and Anna before shipping: the badge goes only on demonstrably most-ordered items, never on what they want to push that week. That is the line between using social proof and faking it. Category order is their call; the badge and the cap are mine.
  5. The consent banner’s button row: accept and reject at the same width and the same weight.
    05

    Symmetric cookie buttons: the pattern I chose not to use

    European regulators have spent two years fining banners that gave “Accept” more visual weight than “Reject”. Beikit’s gives both buttons the same size: same padding, same type, and the only difference is a fill.

    GDPR Article 7 requires it, and it is consistent: every other persuasive pattern here pushes someone toward what they came to do. A dark pattern in a consent banner would push them away from a decision about their own data.

Also shipped

  • Bilingual ES/CA copy, adapted rather than translated
  • Seven fail states under a single rule: never a dead end
  • Three legal pages
  • GA4 with Consent Mode v2 and anonymized IP

The decision I’m proudest of

The layout was approved on desktop. The product is used on a phone.

The live product is a long page: hero, full menu, ordering options, brand story, contact. On mobile that length was costing conversions. People dropped off before reaching the menu or the CTA.

A long page’s key actions live wherever the user happens to scroll past them, which is partly in territory the thumb can’t comfortably reach.

Two findings pointed the same way

Fitts’s Law

Closer, larger targets get acted on faster.

Thumb-zone research

Roughly half of people operate a phone with one thumb, which splits the screen into a natural zone at the bottom third, a stretch zone, and a hard-to-reach zone in the top corners.

Where the thumb actually reaches

  • Hard to reach
  • Stretch
  • Natural reach

Without the bar, the two actions that matter sit wherever the reader happens to have scrolled: usually outside the natural zone, never in the same place twice. With it, they are pinned to the bottom band on every screen. Page length stops being a barrier.

Steven Hoober, How Do Users Really Hold Mobile Devices?, 2013

A phone screen split into three reach bands: the bottom third within natural thumb reach, the middle a stretch, the top corners hard to reach. The key actions appear first scattered up the page, then fixed in the bottom band.CartaPedir

I designed a persistent bottom bar with two shortcuts, “Carta” and “Pedir”. The two actions that matter, permanently inside the natural thumb zone.

It wasn’t in the original PRD. It came from opening the real page on a real phone.

How it was built

From Figma to production without a developer

Early prototypes were validated in Figma, then moved into Lovable to explore structure through vibe coding. We tested hero variants with different product photography and headlines, and different orderings for the sections below.

That is where Carta followed by Pedir came out as the best order past the hero. A competitor’s order CTA sat at the very bottom of the page, which we read as part of why it wasn’t converting. The same hierarchy is what later got anchored in the mobile bottom bar.

After two attempts, Lovable’s chat-based loop didn’t give me the control a brand system this detailed needed. I pivoted the pipeline rather than force the tool.

I designed the full high-fidelity screens in Figma at desktop width. Below 768px I made the responsive calls in the browser instead of drawing a second set of frames: cards from two columns to one, the header collapsing, the Instagram grid from four columns to two, and the mobile-only bottom bar. Never automatic reflow. Each one was a decision I made against the real page on a real phone.

I don’t have screenshots of those early versions. Something I’ll document more carefully next time.

The same hero twice, side by side. Left, the Figma design: the wordmark alone over two product photographs, with “Pide ya” and “Catering”. Right, the live page: a headline over line illustrations, with “Pide ahora”, “Ver carta” and the Google rating.
Left, the hero as designed in Figma. Right, as it shipped: “Catering” became “Ver carta” and the Google rating arrived. The headline and the line illustrations are nowhere in the Figma file, so those calls were made in the browser.

From there, Claude Code with the Figma MCP server pulled design context straight out of those frames. I wrote a brief split into nine sequential phases, so the tool always had one scoped, checkable unit of work instead of “build the site”.

Deployed to Vercel.

  1. 01Tokens and fonts
  2. 02Layout
  3. 03Hero and wave animation
  4. 04Cards and catalog
  5. 05Mobile behaviour
  6. 06The legal layer
  7. 07Forms
  8. 08SEO
  9. 09QA

Reviewed in the browser before moving on

Scope

The page that’s ready, waiting on the green light

I designed and specified a standalone catering page in full: hero, value proposition, four-step explainer, product listing, and the eight-field form the research called for, with real-time validation, a confirmation page and its own consent clause.

It has been finished since before the opening. It isn’t live because Juan and Anna decided to wait: running catering alongside a brand-new store was too much at once. They’ll switch it on when they decide to.

I’m including it because it marks where my work ends and theirs begins. Design, spec and implementation are mine, and they’re done. When to switch it on is a business call, not mine to make or to rush.

The catering form: three stacked groups of tappable options for the type of event, the number of people, and what you want.

The impact

A 25% lift, and what I can’t prove

The result

A ~25% increase in online orders in the weeks after launch, per the founders.

The evidence I have

Directional, not audited. Beikit is a small business with no formal analytics baseline, and I’d rather say that precisely than inflate it.

The signal I can verify myself

The product is still alive because I’m still iterating on it. Juan and Anna see it daily from the counter, customers respond, and that feedback turns into changes: the phone moved from a landline to a direct mobile line, hours were adjusted to real footfall, the catalog was trimmed from five categories to four. None of that was in the original PRD, and I’m still in the loop.

What I’d do differently

Align scope and requirements more rigorously from day one, not because this project lacked it, but because it’s the discipline I want by default, pivot or no pivot. Define which metrics to track during ideation, not after launch: it’s the only way for the 25% to stop being “per the founders” and become auditable. And keep refining how I direct AI: more workflow planning before building, more precise context in the briefs, and features split across several agents instead of one carrying everything.

Reflection

What AI taught me about design, and none of it is about AI

  • Directing isn’t the same as asking

    The gap between asking for “a cool wave animation” and handing over an exact technical spec wasn’t prompt quality. It was how much I already knew before I wrote it. AI doesn’t shrink the distance between a vague idea and a built thing, only between knowing exactly what you want and having it built. Given something vague, it produces something vague, faster and with more confidence. The skill that mattered is the one I use writing level specs: describing a behaviour until there is no room left for interpretation.

  • Building fast doesn’t substitute for looking

    No AI suggested the bottom bar, because it was never in a prompt. It came from opening the real page on a real phone. Building with AI frees up time. That time can go into building faster, or into the one step no AI does for me: looking at the finished product the way a stranger would. The second is what found the real problem.

  • Cheap to build doesn’t mean ready to ship

    Building the catering page in full cost a fraction of what a developer would have, which made it as easy to switch on as to leave waiting. When building stops being expensive, the brake that used to force the question “is this worth it” disappears. Deciding what ships and when becomes the real job.

All three point at the same thing. AI changed how long it takes me to build. It changed nothing about what I still have to know, look at, or decide before I do.


That’s the case. Here’s the rest of the work.