Product design
Product design for complex workflows
UX research, interface design and design systems for platforms, internal tools and apps, delivered in a form your engineers can build without guessing.
For teams whose product has real rules, roles and edge cases, and who need design that survives contact with development.
- Deliverable
- Prototypes and a design system, not static mockups
- Tested
- With the people who will use the product
- Handoff
- Specified for engineers, in English or Spanish
- Research Interviews, observation and analytics
- Structure Flows, roles and information architecture
- Prototype Clickable flows tested with real users
- System Components, tokens and specifications
Research first
Design decisions start from how the work is actually done.
Tested
Prototypes are reviewed with real users before development.
Buildable
Every screen is specified for the engineers who will build it.
The business problem
Complex software usually fails at the interface.
The logic can be correct and the product still fail, because the people using it cannot find what they need, do not trust what they see, or take three times longer than the process should. Design is where those costs are decided, usually before anyone measures them.
Users ask for training to do routine tasks
The interface reflects how the system is built, not how the work is done.
Every screen looks slightly different
No shared components, so each feature invents its own buttons, tables and forms.
Designs that cannot be built as drawn
Mockups that ignore data, states and edge cases, reinterpreted by engineers under deadline.
Features shipped that nobody uses
Decisions made in meetings, never tested with the people meant to benefit.
Dashboards full of numbers, empty of answers
Data on screen without a question it is meant to answer.
A product that looks older than the company
An interface that undermines the credibility of a service that is otherwise sound.
Outcomes
What product design is meant to change.
- 01
Tasks take fewer steps
Flows designed around the job, with the common path short and the rare path still possible.
- 02
Consistency by default
A component library that makes the correct pattern the easiest one to use.
- 03
Fewer surprises in development
States, errors, empty screens and permissions specified before code is written.
- 04
Decisions backed by evidence
Usability findings and analytics behind each change, rather than preference.
Scope
What can we design?
Most engagements combine research, a set of core flows and the components those flows need.
SaaS products
Onboarding, accounts, roles, settings and the core workflow your customers pay for.
Internal tools
Back-office systems where speed and accuracy matter more than decoration.
Dashboards and reporting
Views built around the decisions people make, not the data that happens to exist.
Customer portals
Status, documents, requests and history presented so clients stop emailing to ask.
Mobile app interfaces
Flows for one-handed, interrupted use, consistent with the web product.
Design systems
Components, tokens, patterns and documentation shared by design and engineering.
Redesign of an existing product
Incremental improvement of a live product without retraining every user at once.
Prototypes for validation
Clickable flows to test an idea with users or investors before building it.
Positioning
Design delivered as a system, not as pictures.
A set of polished screens shows what the product could look like. It does not tell engineers what happens when data is missing, a user lacks permission or a request fails. Those answers are part of the design.
Static mockups
- Happy-path screens only
- Visual style decided per screen
- Handed over as image files
- No user testing
- Edge cases resolved in code
- Ends at handoff
ZitDevs product design
- Research with real users
- Flows including states and errors
- Reusable components and tokens
- Tested prototypes
- Specifications engineers can build from
- Design support during development
Fit
Who this service is for.
A good fit when
- The product has several user roles, permissions or complex rules.
- Users complain, need training or build workarounds outside the product.
- A new product needs its core flows validated before development starts.
- Several teams build features and the interface no longer feels like one product.
- Someone can arrange access to the people who use the product.
Probably not yet when
- The need is a brand identity or marketing visuals rather than a product.
- Nobody can give the design team access to users or domain experts.
- The product will be built without any review of the design by engineering.
Process
How a product is designed.
Each stage ends with something you can review, test or hand to an engineer.
Research
Interviews, observation of real work, analytics and a review of the current product and competitors.
Definition
Users, roles, jobs to be done and the flows that matter most, written down and agreed.
Information architecture
Navigation, structure and data relationships before any visual design.
Prototyping
Clickable flows at increasing fidelity, reviewed with stakeholders.
Usability testing
Sessions with real users on the prototype, with findings ranked by impact.
Design system and specification
Final screens, components, states and tokens prepared for development.
Design support in development
Reviews of what is built, answers to engineering questions and iteration after release.
Handoff
Built to be implemented.
Design only creates value once it is shipped. The handoff package is designed for the engineers who will use it, whether that is the ZitDevs development team, your internal team or another provider.
Specified for development
Behavior, validation, states and responsive rules documented alongside the visuals.
Tokens shared with code
Colors, type and spacing defined once and usable directly by engineers.
- Flows
- Every state
- Components
- Reusable
- Tokens
- Shared
- Specifications
- Per screen
Engagement models
How the work is contracted.
Design project
Research, core flows and a design system for a defined scope.
- Written scope and deliverables
- Tested prototype included
- Best for a new product or major redesign
Design and build
Design and development by the same team under one agreement.
- No handoff between vendors
- Designers support the build
- Best when ZitDevs develops the product
Embedded designer
Ongoing design capacity alongside your product team.
- Agreed monthly capacity
- Continuous research and iteration
- Best for an evolving product
Why ZitDevs
What makes the design work usable.
Designers who work with engineers
Design and development sit in the same company, so feasibility is checked while decisions are made.
Tested, not assumed
Core flows are tested with real users before development, and findings are shared in writing.
Bilingual interfaces
Products designed and written in English and Spanish, with layouts that hold for both.
Accessible by default
Contrast, focus, keyboard use and readable type are requirements, not extras.
FAQ
Questions about product design.
Answers are written for this service. Where a figure depends on your situation, we say so instead of publishing an average.
How much does product design cost?
Cost depends on the number of user roles and core flows, how much research is needed, whether a design system is included and whether the product already exists. We give a written estimate after an initial conversation, with the scope and deliverables stated.
How long does a design project take?
It depends on the scope of the first set of flows. We sequence the work so that the highest-value flows are designed and tested first, and development can start on them while the rest continues.
Do you design only, or also build?
Both. Design can be delivered on its own, or as part of a design and build engagement where the same company develops the product. Design-only work is specified so any engineering team can implement it.
Can you redesign an existing product without disrupting users?
Yes. We usually recommend an incremental approach: improve the highest-impact flows first, introduce shared components gradually and measure the effect of each change.
Do you conduct user research?
Yes. Research can include interviews, observation of real work, analytics review and usability testing. The depth is agreed per project according to what decisions need evidence.
Which design tools do you use?
Typically Figma for design, prototypes and component libraries. Files and libraries are handed over as part of the deliverables.
Can you create a design system for our product?
Yes. That includes components, tokens, patterns and usage documentation, designed to match how your engineering team builds the interface.
Who owns the design files?
Ownership of deliverables is defined in the contract for each engagement, before work begins.
Tell us which workflow is slowing people down.
Describe the product, who uses it and where they struggle. We will come back with a design scope, the research it needs and a plan for getting it built.
The form is preselected for product design, so the questions match the project.