# Product Design > User research, wireframes, prototypes and design systems that survive contact with engineering, delivered inside the same Pod as the build. Source: https://www.koombea.com/capabilities/product-design/ --- A design that cannot be built as drawn is not a design, it is a picture. Ours are produced in the same Pod that ships them. ## The problem The usual failure is organizational. Design happens in one company, engineering in another, and the handoff is a file. Every ambiguity in that file becomes a decision an engineer makes alone, at speed, without the context that produced the drawing. Because design and delivery sit in the same Pod here, each flow is validated as a clickable prototype before implementation, and the design system is built as real components rather than as a library of symbols nobody can use. We also research before we draw. Not a six-week study, but enough contact with actual users to know which of the three plausible flows matches how people already think about the task. - Clickable prototypes to validate direction before a line of code - Design systems delivered as usable components, not just as files - Research sized to the decision, not to a template - Accessibility considered in the flow, not bolted on at the end ## What this covers - **Product and UX design**: Flows, wireframes, and interface design for real products. - **Prototyping**: Clickable validation of direction before implementation starts. - **User research**: Interviews and testing scoped to the decision at hand. - **Design systems**: Components, tokens, and documentation engineering can actually use. - **Accessible by design**: Contrast, focus order, and semantics decided during design. - **Figma delivery**: Handover that matches what gets built, because the same Pod builds it. ## UX and UI Are Not the Same Purchase ### UX — Whether the flow matches the task. User experience is a question about structure. Which screens exist, in what order, what happens when something is missing, and whether the path matches how someone already thinks about the job. Get this wrong and no amount of interface work recovers it. - Flows validated as a clickable prototype before implementation - Empty, loading, partial, error, offline, and permission-denied states decided in design - Accessibility built into the flow, including focus order and semantics - Platform conventions respected, because iOS, Android, and the web do not behave alike ### UI — Whether the surface is usable and yours. The interface layer carries the brand and does the moment-to-moment work of being legible, tappable, and unambiguous. We build it as a design system of real components rather than a page of symbols, so the second screen costs less than the first. - A design system delivered as components engineering can use - Contrast and target sizes checked against WCAG, not eyeballed - Your brand carried through the product, not a template with a logo dropped in - Decisions driven by what works rather than by what is current Most requests for "design" arrive meaning the second one. The first is where the money is usually lost, because a beautiful interface over the wrong flow is a faster route to the wrong place. ## How Design Runs Inside a Pod Frame the decision: The question your design has to answer gets written down before anything is drawn. (Days, not a discovery phase) Draw and prototype: Your flows become a clickable prototype. Redirecting a prototype costs a fraction of redirecting an implementation, which is the entire reason it exists. (Cheap to change, on purpose) Test on the prototype: Usability testing happens before implementation rather than after your launch, while the answer is still free to act on. (Five or six conversations, usually enough) Hand to the same Pod: Design runs roughly a cycle ahead of implementation, in the same Pod that ships it. No file goes over a wall, so ambiguity gets a conversation instead of a guess. (One cycle ahead, rolling) Grow the system: Patterns that recur become components in your design system, so each later surface costs you less to design and less to build. (Compounding, not linear) ## Research sized to the decision Research has a bad reputation in product teams, and it earned it honestly. Six-week studies that arrive after the decision was made are theatre, and everyone involved knows it. So we size research to the decision in front of us. If the question is which of three plausible flows matches how people already think about a task, that is five or six conversations and two days, not a discovery phase. If the question is whether an entire product category is worth entering, that is a bigger piece of work and it should be a separate engagement rather than smuggled into a build. The test we apply is simple. If the finding could not change what we build next, we do not run the study. That constraint keeps research cheap enough to actually happen, which is the only way it affects anything. - The question is written down before the method is chosen - Usability testing on the clickable prototype, before implementation rather than after launch - Existing analytics and support tickets read first, because you often already have the answer - Findings delivered as decisions and open questions, not as a slide deck nobody opens ## When the product does not exist yet Sometimes the honest answer is that you have nothing to design yet, because the shape of the thing is not decided. That work is discovery, and it produces artefacts rather than screens. What you get out of it is the material your estimate can be built from. A backlog broken into epics and user stories, a high-level architecture stating what your system has to talk to, and a service blueprint showing where your product touches your operation. Those three turn a vision into a scope that can be priced in story points. Discovery is a separate engagement, not something smuggled into your build. It is also the right first step more often than people expect, and you will be told that rather than handed screens for a product nobody has bounded yet. - A backlog as epics and user stories, which is what gets priced - High-level architecture, so integrations are known before they surprise you - A service blueprint, showing where the product meets your operation - A scope that can be estimated in story points rather than in optimism ## What drives the estimate Design and engineering come out of the same capacity here, so design work competes with features rather than sitting in a separate budget you forget about. That makes it worth knowing what actually costs. The answer is states, not screens. A screen is one drawing. A screen with empty, loading, partial, error, offline and permission-denied variants is six, and those variants are exactly what gets skipped in a handoff and then invented by an engineer at speed. - Distinct states per surface, which is the real unit of design work - Whether Tambora can be the starting point or the product needs its own visual language - The accessibility conformance level, if one has to be verified rather than merely intended - How many platforms the design has to survive, and whether they can share patterns - Research depth, which we size to the decision rather than to a template ## Start with a free design audit If you already have something built, the cheapest way to find out whether this capability is worth buying is to watch us assess your product first. A written heuristic audit, back in two to three business days, at no cost. ## Questions worth asking ### What is the free design audit, and what is the catch? It is a heuristic review of a product you have already built, returned as a written report and a prioritized list of usability issues in two to three business days. The catch is that we hope you like the work enough to talk about the rest. The documents are yours either way, and most audits do not turn into engagements. ### Can we bring our own designer? Yes, and it works well when the boundary is clear. Your designer owns the visual direction and the flows; we own buildability and the state coverage. What does not work is a handoff with no conversation, because every ambiguity in the file becomes a decision an engineer makes alone. ### Do we get the Figma files? You do. Designs, source and documentation all become your property on full payment. The design system ships as usable components rather than only as a library of symbols. ### Is design a separate phase before development? No. Design runs ahead of implementation on a rolling basis inside the same Pod, typically a cycle or so in front. A long design phase before any code produces beautiful work that has never met a real constraint. ### What if we do not like the direction? That is what the clickable prototype is for, and it is deliberately early and cheap to change. Redirecting a prototype costs a fraction of redirecting an implementation, which is the entire reason we validate before building. ### Do you do brand and marketing design too? Product design is the capability we sell. We handle the product surface and the design system it needs. Full brand identity work is outside this and we will say so rather than take it on badly. ## Awarded product work since 2019 Every Indigo Design Award this design work has taken since 2019, with the category it was given in and the product it was given to. ### 2025 (8 awards) - Silver in Mobile App: Kunstrux - Silver in UX, Interface & Navigation: Purgo - Bronze in Mobile App: Gratitude - Bronze in UX, Interface & Navigation: Kunstrux, Draymatics, Gratitude - Bronze in Website Design: Purgo, Draymatics ### 2024 (10 awards) - Silver in Apps: FCC, DEVNAUT, Tuily - Silver in Mobile App: Sword and Scale, Tuily - Silver in UX, Interface & Navigation: DEVNAUT, Tuily - Bronze in UX, Interface & Navigation: Sword and Scale, FCC, Tuily ### 2023 (14 awards) - Gold in Mobile Responsive Design: RefMasters, Fashioned Health - Silver in Mobile App: RefMasters, Fashioned Health - Silver in Mobile Responsive Design: Trainerz, Wait Time - Silver in UX, Interface & Navigation: Wait Time, NINI and LOLI - Bronze in Mobile App: Trainerz, Wait Time - Bronze in UX, Interface & Navigation: RefMasters, Trainerz, Fashioned Health - Bronze in Website Design: NINI and LOLI ### 2022 (12 awards) - Gold in Mobile Responsive Design: Do It Center - Silver in Mobile App: Avidus, Do It Center - Silver in Mobile Responsive Design: Minnect - Silver in UX, Interface & Navigation: Avidus, Minnect, Do It Center - Bronze in Mobile App: Minnect - Bronze in Mobile Responsive Design: Avidus - Bronze in UX, Interface & Navigation: Joynup - Bronze in Website Design: Joynup, Do It Center ### 2021 (5 awards) - Gold in Interactive Design: Koombea - Gold in Mobile Responsive Design: Koombea - Gold in Website Design: Koombea - Silver in UX, Interface & Navigation: Koombea - Bronze in Animation & Illustration for Websites: Koombea ### 2020 (8 awards) - Gold in Mobile App: Luna - Gold in Mobile Interaction & Experience: Nab - Gold in Website Building Software: LINCSPRING - Silver in Interactive Design: Nab - Silver in UX, Interface & Navigation: Nab, LINCSPRING, Luna - Silver in Website Design: Nab ### 2019 (1 award) - Gold in UX, Interface & Navigation: FlightLogger ## Where to go next - Free Design Audit: A written heuristic review of what you have already built - Auditoría de diseño: La misma auditoría, en español - Product Engineering: The capability design runs a cycle ahead of - Nab: Case study, and an Indigo winner - How Pricing Works: How design work gets priced alongside the build