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.
Name the person and the task.
Describe who will use the app, the situation they are in and how they handle the task today. “People who want to be organised” leaves too many questions open. “A tutor who needs to find a saved lesson recording before a class starts” gives the design a concrete starting point.
Explain the inconvenience in observable terms. Is someone searching several folders, entering the same information twice or asking a colleague for an update? Include an example of the current process, with private details removed.
Write one complete first-release journey.
List the steps from opening the app to finishing its main job. For an illustrative lesson library, that might be: add a recording, give it a recognisable title, put it in a lesson category and find it again for playback.
Separate essential steps from later ideas. Sharing with a class, automatic transcripts and paid memberships could each be useful, but they introduce different questions. Keep them in a later list unless the first release cannot serve its purpose without them.
Three lists worth writing
- Feature 1
Must work: the actions needed to complete the main task.
- Feature 2
Can wait: ideas that add value after the main task works.
- Feature 3
Uncertain: decisions that need design exploration or technical investigation.
Explain where information comes from.
Say what people enter, import or receive, and where that information needs to be available. A library used on one device has different requirements from a shared library that updates across several devices.
Identify any accounts, payments, business systems or external services involved. You do not need to choose the implementation in the brief. State the required behaviour and who can provide access or answer questions. Use sample data rather than customer records, passwords or payment details.
Make the constraints visible.
Name the intended devices and any existing app, design files, brand assets or store account. Explain accessibility needs you already know about and the situations where the app will be used, such as an unreliable connection or a busy workplace.
Include the budget range you are comfortable discussing, a target date and the reason for that date. Distinguish a fixed event from a preference. Name the person who will make decisions and the people who need to review the work; unresolved approval steps can delay an otherwise clear project.
Constraints worth naming early
- Feature 1
The intended devices, and any existing app, designs or brand assets.
- Feature 2
Accessibility needs, and the situations the app will be used in.
- Feature 3
A budget range, a target date, and the reason behind that date.
- Feature 4
Who makes the decisions, and who else has to review the work.
An example you can adapt.
This is an illustrative brief, not a description of a Zynx client project: “Independent tutors need to find their saved lesson recordings on an iPhone before a session. Today they search folders with inconsistent filenames. The first release should let a tutor import a recording, name it, assign a lesson category and play it later without a connection.”
“The first release is for one person using one device. Class sharing and transcripts are later ideas. We have a logo and sample recordings, but no screens yet. Before agreeing development, we need to decide which file types to support and how a tutor recovers from a failed import.”
Finish with a way to review the result.
Turn the main task into a few observable checks. In the example, a tutor should be able to import a supported sample recording, find it in the chosen category and play it after closing and reopening the app. Define expected behaviour for a missing or unsupported file too.
Send the brief with your sketches, questions and unknowns. A useful first conversation should clarify those unknowns and identify the next decision. You do not need to settle every feature before asking for help.
Common questions
Frequently Asked Questions
How detailed does my first brief need to be?
Start with the intended user, main task, essential first-release features and known constraints. A short brief with explicit unknowns is useful for an initial discussion.
Should I include apps I like?
Yes, if you explain the specific behaviour or design choice that is useful. “This makes the next action clear” is more actionable than “make it look like this”.