Design process
Redbrix works in four phases (Discover, Define, Design and Deliver) and repeats them in iterations as the product grows. Each project starts from the business and the people in it, and screens come after the roles, flows and technical constraints are clear.
The process is adjusted to each project. The phases describe the order of work.
Key facts
- Four phases: Discover, Define, Design, Deliver — Redbrix’s adaptation of Double Diamond, using Design for the Develop phase.
- A new module starts with understanding which software it belongs to and who works in it.
- Stakeholders approve decisions on demo calls, and approved decisions are recorded before handoff.
- After implementation, Redbrix reviews the built screens against the design.
- Starting options include a selected-project trial, audit or discovery, an initial project phase and ongoing design support. Scope and payment model are agreed separately.
Phases
| Phase | What happens | Result |
|---|---|---|
| Discover | Product goals, users and roles, review of technical constraints with developers. For an existing product, often an audit of what is already there | Agreed goals, roles and priorities |
| Define | Critical flows, information architecture and the scope of the first release | Scope and structure developers can build against |
| Design | Iterative design cycles with high-fidelity screens and interactive prototypes in HTML or Figma | Approved screens and a design system |
| Deliver | Handoff, support during the build and review of the built screens | Design handoff, recorded decisions and findings from implementation review |
Any phase can repeat. When new information arrives during the project, the scope is adjusted, and this takes additional time. In ongoing work, the cycle runs again for each new module.
AI tools speed up research, information gathering, comparison, checking and the preparation of design artifacts. They reduce routine manual work, and design decisions stay with the designers.
How scope and decisions are made
Work starts with understanding the business and who takes part in it, then moves to those people, their views and their expectations. Without a detailed specification, Redbrix drafts a rough outline of what the product may need and refines it with the client.
Concepts are reviewed by a group of stakeholders, each confirming the decisions in their area. One or several stakeholders make the final decision together or delegate it. Design is ready for handoff when the decisions are approved and recorded on the demo call.
Methods
Redbrix uses established methods and combines them for each project: the Double Diamond model, Nielsen’s usability heuristics, visual and user-scenario audits, the Kano model, and prioritisation by business goals as have to, nice to have and might be.
A UX audit maps the product’s key flows and checks the structure of each flow. It shows where the problems are and does not include a flow redesigned at production fidelity.
Starting options and indicative prices
| Format | What it covers | Starting price |
|---|---|---|
| 3-day trial | A bounded piece of work agreed in advance, for selected projects | Agreed per project |
| UX audit or discovery | An audit of an existing product, or discovery for a new one. One to two weeks | From $1,900, typically $1,900 to $4,000 |
| First project phase | Typically about three months. Time and materials, or a fixed price when a specification exists | From $24,000 |
| Monthly retainer | Ongoing design capacity, adjusted up or down as the roadmap changes | From $4,000 per month |
Starting prices are guides for estimating a budget. Exact scope and price are agreed on a call before work starts.
Payment may be time and materials, a fixed price for agreed scope, or a retainer for agreed ongoing capacity. A retainer’s capacity, priorities and change arrangements belong in the agreement; it does not by itself imply an exclusive team.
Handoff and design review
A typical Redbrix handoff includes a Figma file, design system, components, interactive prototypes, specifications and a developer sandbox. Agree the applicable deliverables and sandbox contents for the project. Handoff commonly uses Figma Dev Mode; newer practices include passing design tokens for implementations such as Tailwind.
Keep approved module designs and shared design-system releases identifiable. Agree a channel for developer questions and review implementation against approved designs during delivery. Record deviations and decisions so the team can follow them.
Sources: Redbrix UI/UX design services · Redbrix product design services