DESIGN
Pix and Build
Role & scope
Full UX/UI design. Design-only project, from problem research to the visual styles system.
Stack in context
Designed in Figma. Graphic assets with Illustrator and Photoshop.
Technologies
FigmaIllustratorPhotoshop
DESIGN
Full UX/UI design. Design-only project, from problem research to the visual styles system.
Designed in Figma. Graphic assets with Illustrator and Photoshop.
The pandemic accelerated the adoption of QR digital menus, but the solution was always a PDF, hard to maintain, impossible to consume on mobile and with no separation between content and design. Pix and Build was born to solve that.
During the 2020 pandemic, restaurants massively adopted digital menus via QR code. But the solution was almost always the same: a PDF uploaded to the cloud or a Google Drive document. The problem was twofold. Menus with poor design were functional but unappealing. Menus with good design were visually careful but impossible to consume on mobile, they weren't designed for small screens, constant zooming was required and the experience was frustrating. Additionally, any price or dish change required redoing the document from scratch or intervening on a complex file. The opportunity was clear: separate content creation from visual presentation, and design the experience with mobile as the primary consumption medium.
The flow was born on paper. Several hand-drawn wireframes led to the conclusion that separating content and design into two distinct modes was the best way to eliminate user mental dispersion and focus each task on a single goal.
Two users with different roles in the same product. The restaurant owner, who doesn't need to have design knowledge, needs to create and maintain their menu without friction: adding dishes, updating prices, organising categories. The diner, who consumes the menu on their mobile, probably in the restaurant itself, needs to find what they're looking for quickly and with a visually pleasant experience. The product design had to serve both without either noticing the complexity behind it.
Three flows defined the design priorities. The first: menu creation, the owner being able to structure categories, add dishes with name, description, price, extras, labels and images without mental dispersion. The second: visual style selection and configuration, the owner being able to choose from over 50 styles and configure price visibility, images, navigation and currency without touching the content. The third: the diner's experience, the resulting menu being readable, navigable and visually attractive on any mobile, without needing to zoom.
The process started with paper wireframes. The first exploration was a unified editor where content and design coexisted on the same screen, the owner could see in real time how the menu looked while editing it. It was discarded because it mixed two cognitively very different tasks: organising information and making aesthetic decisions. That mix generated dispersion and slowed both tasks down. The conclusion, reached independently, was the same that tools like Webflow or Notion use: structured content first, then presentation. Two separate modes, two clear goals, zero dispersion.
The central decision was architectural, not visual: separating content and design into two distinct modes to eliminate mental dispersion. Everything else, the 50+ styles, the configuration options, the subscription model, derives from that initial decision.
Pix and Build is the only project in the portfolio that never reached development. In 2020 the stack needed to implement it exceeded the available skills. Today that gap is closed, it is exactly the type of project that the current hybrid profile can take from design to production.
Although the project never reached development, the component architecture was implicit in the design. Content mode required reusable form components, the same dish component worked for any category. Design mode required a system of interchangeable themes where each style was a presentation layer applicable over the same data structure. Today that architecture would be implemented naturally with React and CSS variables or design tokens, each style would be a theme that overwrites the base tokens without touching the component structure.
The project never reached code in 2020. But the design already anticipated the most obvious implementation problems: how to make 50+ styles maintainable without duplicating code, how to handle asymmetric content without breaking any layout, how to separate the data layer from the presentation layer so both could evolve independently. Those questions, which in 2020 were left without a technical answer, today have a clear solution with design tokens and theming in React.
A complete design product that never reached development due to lack of technical skills at the time. Years later, companies in the sector validated the same hypothesis by taking it to production. The gap that prevented implementation in 2020 is now closed.
Pix and Build remained as a design project without implementation. However, the hypothesis behind it, separating content and design to democratise the creation of attractive digital menus, was subsequently validated by companies in the sector that took similar solutions to production. That the same idea emerged independently and reached the same architectural conclusions is the best possible validation that the problem was well identified and the solution well conceived.
In 2020 the project stalled due to lack of technical skills to take it to code. Today that gap is completely closed, it is exactly the type of project that the current hybrid profile can take from design to production autonomously. If I were to pick it up today, I would start with an MVP covering the two critical flows, content mode and design mode, with 10 initial styles, without trying to build the complete system from the start. I would also seek to validate with real restaurant owners before designing the second version, something that in 2020 I couldn't do beyond a single informal presentation.
The product was organised in three areas. The first is the menu manager, a centralised view from which the owner accesses all their menus, previews them and manages them. The second is content mode, where the menu structure is defined: categories, dishes, prices, extras, labels and images. The third is design mode, where the visual style is chosen and the presentation is configured: price and image visibility, navigation type, element order and currency. The three areas are connected but cognitively independent, the owner can be in any of them without the others interfering.
Separating content mode from design mode was not an interface decision, it was a decision about how human attention works. Organising information and making aesthetic decisions are two cognitively different tasks that interfere with each other when they happen simultaneously. By separating them into two independent modes, the owner can focus on a single thing at each moment: first build the menu, then choose how it looks. That separation reduces cognitive load, speeds up both tasks and produces better results in both.
The decision to offer over 50 visual styles was not arbitrary, it was incremental. It started with 10 initial styles and more were added as new needs emerged. Styles were organised by three criteria: the emotion they convey, their visual aesthetic and the type of restaurant they best suit. That taxonomy allows the owner to find their style not just by appearance but by identity, a minimalist Japanese cuisine restaurant has different criteria than an informal pizzeria. The style system also had a business dimension: some styles would only be available in higher subscription plans, turning the catalogue into a conversion incentive.
The configuration options in design mode, price and image visibility, navigation type, element order, currency, were not defined solely for utility. When exploring the business model it became clear that these options could work as a differentiator between subscription plans: basic configurations available in the free plan, advanced ones reserved for paid plans. That logic turns each configuration option into a product decision with direct impact on conversion and user retention.
The diner consumes the menu on their mobile, in the restaurant, probably with one hand while holding a glass with the other. Designing mobile first was not a stylistic choice, it was the only constraint that mattered. Every visual style, every navigation configuration, every typographic decision was evaluated on small screen first. If it didn't work on mobile, it didn't work. That constraint automatically eliminated many design options that would have been valid on desktop but frustrating in the real context of use.
Pix and Build's visual system has a unique particularity: there is no single visual system, there are over 50. Each style is a complete and independent visual system with its own typography, colour palette, image treatment and navigation style. The challenge was not to design a system but to design a meta-system: a set of rules that allowed creating very different styles without any of them breaking the user experience or content readability.
The most complex case was the menu with very asymmetric content, categories with a single dish alongside categories with twenty, dishes without images alongside dishes with high-quality photography, one-line descriptions alongside long descriptions. Every visual style had to behave correctly in all those cases without the owner having to do anything special. Styles that didn't pass that asymmetric content test were discarded or redesigned.