What this service solves
Most digital products don't fail for lack of technology: they fail because nobody decided what the user should see first. This service puts interface and experience design where it belongs —before building, not after— and documents it so the team can keep working without depending on whoever designed it.
Problems we solve
- A product with good technology that nobody understands in the first thirty seconds.
- Internal dashboards the team avoids because asking for the number over chat is cheaper.
- Screens designed one by one that no longer look like each other.
- AI interfaces where the user doesn't know what to ask or whether to trust the answer.
- A design that looks right in the deck and breaks on the client's phone.
What's included
- Information architecture: which screens exist and how they relate.
- Interface design for the key screens, on desktop and mobile.
- Design system: color, typography, spacing, components and states, with written rules.
- Interface patterns for AI features: input, waiting, result, error and human correction.
- The states almost nobody designs and everybody hits: empty, loading, error, no permission and no data.
- Accessibility criteria applied from the design stage: contrast, focus, hierarchy and touch targets.
- Development-ready handoff, with the decisions explained.
How we work
- Understand what the product does and who actually uses it, not who we'd like to use it.
- Review what already exists before proposing anything new.
- Design first the screens where the business is decided.
- Write the design system while designing, not at the end.
- Review on the real device, not in the mockup.
What we need from your team
- Access to the current product, if it exists, even if it's half-built.
- Who uses it and what for: two or three real profiles are enough.
- The business decisions the interface has to support.
- One person on your side who can say yes or no.
What you receive
- Screens designed for desktop and mobile, ready for development.
- A design system with components, states and usage rules.
- Behaviour specification: what happens on click, on failure and while waiting.
- A decisions document: what was discarded and why.
Who it's for
- Companies building a digital product that haven't designed its interface yet.
- Teams with an internal dashboard their own people avoid.
- Products with AI features that need an interface people can trust.
- Brands whose product no longer resembles their website — or itself, screen to screen.
Signs you need this
- Every new screen is argued from scratch because there are no written rules.
- The development team asks which color or which spacing to use.
- Users ask for training on something that should explain itself.
- The product works, but the sales demo is harder than it should be.
Expected outcome
The product ends up with an interface that needs no manual, a design system the team can follow without asking, and documented decisions so the next screen doesn't start from zero.
Technology stack
- Figma
- Design tokens
- HTML5
- CSS3
- JavaScript
- Sistemas de diseño
- WCAG 2.2