Work with Zynx
Bring a brief, a prototype or an existing app.
We design and build apps for iPhone and iPad. Share where your project is now and we will discuss the people it serves, the work involved and a sensible next step.
Choose one uncertainty worth exploring.
“Does the app look good?” invites opinions about colour and taste. “Can a new user save an item and find it again?” gives you a task to observe. Other useful questions concern the meaning of a label, the order of a form or whether people understand the result of an action.
Write the question beside the prototype scope. If you have several unrelated questions, prioritise them. A smaller, complete journey can teach you more about a decision than many disconnected screens.
Include the beginning and the result.
Start the journey where a person would naturally encounter the task. Include enough context to explain what is available, and end with a visible result. People need to understand whether their action worked, where the item went and how to continue.
Use plausible names, quantities and content. Add a long title or an empty collection when those states matter to the question. You can simplify unrelated areas, but identify the parts that are simulated so reviewers know what the prototype covers.
A small example: saving a recording.
Imagine a lesson library prototype. The question is whether a tutor understands how to organise a newly added recording. This is an illustrative design exercise, not a report of customer research.
The journey begins with an empty library, offers an import action, shows a sample recording, asks for a lesson category and returns to the library. The task is: “You have a recording for next week’s lesson. Save it somewhere you can find before the lesson begins.” Avoid telling the participant which buttons to press.
A useful observation might be that the person looks for “Save” while the screen says “Done”, or believes choosing a category moves the original file. Those observations identify language or behaviour that needs explaining; a general request for a brighter button does not resolve the same question.
Record behaviour before collecting opinions.
When reviewing with someone from the intended audience, let them attempt the task before explaining the design. Note where they pause, what they try, what they expect and whether they recognise completion. Ask neutral follow-up questions such as “What did you expect to happen there?”
Keep observations separate from interpretations. “Opened the category menu three times” is an observation. “The category label may be unclear” is a possible explanation to investigate. A short session gives evidence about that interaction, not proof that the whole market wants the product.
What to write down in a session
- Feature 1
Task: what the person was trying to accomplish.
- Feature 2
Observation: what they actually did or said.
- Feature 3
Interpretation: why the difficulty might have happened.
- Feature 4
Next action: a design change or a question to investigate.
Know which questions need a working build.
A screen prototype can explore navigation, language and interaction flow. It cannot by itself establish file import reliability, background playback, syncing, payment processing or performance on a real device.
If the central uncertainty is technical, define a small working experiment with the development team. Keep design findings and technical findings distinct in the project notes so a convincing animation is not mistaken for completed functionality.
What a screen prototype cannot prove
- Feature 1
File import reliability and background playback.
- Feature 2
Syncing between devices.
- Feature 3
Payment processing.
- Feature 4
Performance on a real device.
End with a decision and an updated design.
Review the original question against the observations. Decide what to keep, change or investigate, and explain why. Update the flow and associated screens together, including relevant empty, error and completion states.
For handover, include the prototype’s coverage, the agreed behaviour and unresolved questions. This gives development a more useful starting point and prevents the same decision from being reopened without its context.
Common questions
Frequently Asked Questions
Does every screen need to be in the prototype?
Include the screens and states needed to explore the selected journey. Record what is outside its coverage so reviewers do not assume the whole product has been designed or tested.
When is a prototype ready for review?
When someone can attempt the intended task, see a result and provide useful evidence about the question you chose. Visual polish should match what you are trying to learn.