UI/UX product design can be commissioned separately from development when a team needs clearer workflows, interfaces or design direction. Zoha can help investigate the task, review alternatives and deliver editable design material. The scope should state which decisions the work will resolve, how users and stakeholders are involved and what the implementation team receives.
Updated
On this page
Decide what the design engagement must solve
A new product, an inconsistent interface and a confusing operational workflow need different design work. Identify the users, the decisions they make and the evidence of difficulty. Separate an observed issue from a preference for a different visual style.
If development is already underway, invite the implementation lead into the starting discussion. Existing constraints and component behavior can influence the solution. Design should make tradeoffs visible rather than hand over a visually finished answer that cannot be built within the agreed scope.
Zoha works from Addis Ababa with local and remote product teams. Bring examples in the languages, record formats and device conditions the intended users encounter. If a workflow needs Amharic labels or different layouts for long records, include those cases in the prototype and review rather than leaving them for the developer to guess.
Choose a representative slice of the product
| Experience | States worth reviewing |
|---|---|
| First use | Orientation, missing setup and a completed first task |
| Daily work | Normal content, empty results and an unusually long record |
| Review or approval | Pending, accepted, rejected and corrected work |
| Failure or interruption | Useful feedback, recovery and a clear next action |
These are examples of coverage, not a requirement to redesign every screen. Select the experiences that reveal important product decisions, then use reusable patterns where the relationship is genuinely consistent.
Review alternatives with a reason for each
A prototype can compare information order, navigation or interaction approaches before a full interface is produced. Explain which task each option supports and the questions that remain. A more polished screen should not automatically win a review.
Consider a hypothetical service-request form that asks every visitor for twelve fields before establishing which details apply. One alternative asks for the request type first, then shows the relevant questions. Test whether people understand the categories, whether an essential detail is hidden and what happens when someone selects the wrong category or changes an earlier answer. This is a design hypothesis, not a measured client improvement; a shorter form is not automatically a better one.
Use feedback without turning it into a vote on taste
- Agree who makes product decisions and who provides specialist input.
- Give reviewers realistic goals and representative information without coaching them through the interface.
- Record observations separately from proposed solutions.
- Explain how a change addresses a task, constraint or accessibility need.
- Keep unresolved questions visible for the next review.
Where direct user participation is included, agree recruitment and how observations will be handled. A limited review can uncover useful problems, but it should not be presented as proof that the design suits every user or situation.
Leave a handover that can guide development
Editable files should be organized around the product and include the relevant responsive layouts, interaction states and reusable components. Notes should explain consequential behavior and any assumptions awaiting a decision. The exact deliverables depend on the implementation team and selected scope.
Agree review rounds, ownership and how questions will be resolved during implementation. Design-only delivery should not imply that the final application has already been built or tested. A combined design-and-development engagement can include later checks that the implemented behavior matches the agreed design.