Understand use
Audience, tasks, roles and content. Review available evidence and identify questions needing research or confirmation.
SNUHY / UX + UI
User experience and interface design
Plan user tasks and flows, then review interfaces and interactive prototypes before development starts.
01 / SCOPE
Design the task, not just the screen.
An attractive screen is not enough if people cannot finish their task. Start with the audience, tasks, content and constraints, reviewing the existing experience where available. Identify the core flows and difficult or unclear states, then develop structure, prototypes and interfaces that fit your identity. Review mobile layouts, Arabic and agreed languages, action labels, errors and empty states. The handover defines component behaviour and relationships between screens rather than isolated images. Interviews, user testing and field research depend on an explicit scope and available participants; do not assume research findings or measured improvements.
Structure and flows
Navigation, steps and alternative outcomes, with wireframes before visual polish.
Interfaces and states
Screens and components covering loading, errors, empty states and interactions in agreed sizes and languages.
Developer handover
Organised files, prototype, usage rules and behaviour notes, with asset ownership and implementation boundaries.
02 / INTERFACE
Design is more than one screen.
Consider what people see before and after a result, and how they recover from errors. This illustrates search-interface states, not a functioning search service.
Search for a topic
?
Start with a clear question.
A label and example help people understand what to enter before they begin.
Illustrative example, not client work or a ready product. No information is collected or actual permissions changed.
03 / DELIVERY
From the task to a prototype we can review.
- 01
Review the product and tasks
Identify users, important journeys and observed issues, separating evidence from assumptions.
- 02
Map the flow
Review content order, navigation and alternative states before approving visual direction.
- 03
Design and validate the agreed scope
Create screens, components and interactions. Real user testing requires a plan, participants and appropriate data consent.
- 04
Document the handover
Define versions, states and sizes, distinguishing prototype behaviour from later development and integration.
04 / BRIEF
Share the product and the task to improve.
Start with the actual need and what exists. Agree scope, outputs, cost and operating responsibilities before implementation.
Discuss your projectProduct link or idea, users and priority tasks.
Observed problems, content, identity and research you may share.
Screens, languages, devices, technical constraints and approver.
Design only, or prototype, research and implementation review too?
05 / Q&A
Before we begin.
01Does design include development?
Not automatically. The proposal names screens, files and prototype. Development, backend integration and operating tests are separate items if requested.
02Can you improve an existing product?
Yes. Review its flows, issues and components to decide what to preserve. Access to user data or analytics needs a defined purpose and authorisation.
03Do you conduct user research and testing?
Agree the research, participants, method and outputs first. A design opinion is not a user test; interviews, findings and improvements are never invented.
04Does the prototype work like the finished app?
It demonstrates agreed flows and interactions, not a live system, database or payment service. Document simulation limits and implementation needs.
05What about Arabic and accessibility?
Define reading direction, languages and sizes, then review contrast, labels, focus and states. Formal compliance or audit requires explicit tests and scope; design is not certification.
06What is delivered and how do revisions work?
Agreed screens, states, components, files and notes, with review rounds and approvals. Product-function changes after flow approval may require additional scope.
06 / REFERENCES
References for defining the work.
References help define design and implementation requirements. They do not imply certification or guaranteed outcomes.
SNUHY / NEXT