I have a project in which I need to do 80 UI mockup screens.
Should I pass these 80 mock-ups to the development team after I've finished all of them, or should I pass it to them in batches of e.g. 10-20?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this communityI have a project in which I need to do 80 UI mockup screens.
Should I pass these 80 mock-ups to the development team after I've finished all of them, or should I pass it to them in batches of e.g. 10-20?
I normally pack it respecting the tasks or sub-tasks, according to the priority order from the product owner/teamlead (more urgent first), so that when developers are going into the sprint, they have all they need for the feature they are about to start working on.
Normally for me it's 2 to 5 screens per sprint per team, so if you are working with two teams in tempo two sprints per month, you will end up delivering 15-30 screens, supported by things like user flow maps.
Additionally, when I am starting a project, I start by doing first rough screens to give the coder the idea of what will be going on in UI, to sort of establish UI preliminary guidelines and to give the frontend people the idea of elements that will be employed in the app, to establish kind of a bootstrap library.
What falls into first category is fonts, color palette, margins and spacing, and in second category there are typical elements like entry forms, tooltips, ajax elements , floating buttons, and datavis components. It helps tremendously to push it all into two separate docs that will be edited and evolving in the course of the project. However, this depends on the team preferences, some people do not like to work like that and it all is a subject for negotiation/discussion.
I try to avoid anything like passing 80 pages to a development team.
There are lots of reasons for this. Cognitive theory shows it's very hard for anyone to absorb 80 chunks of information. Modern design practice is iterative or agile, and results in much better collaboration with developers and product derisking than waterfall style models where large chunks of information are passed from design to development.
Generally I try to bring developers into the design process early through low-fidelity storyboarding. This allows them to think through architecture and provide feedback on areas of technical complexity. It also allows us to establish clear flows and subflows in the UX, which the developers understanding holistically so they are clear on how the pieces work together.
Then during design the UX guys create wireframes top down....starting from general page wireframes and high level, low-fi flows. These get passed onto the dev team so they can keep planning.
The high level flows then get broken down into sub-flows, which are generally 1 to 10 pages. This is a very manageable chunk of information, and each sub flow gets passed onto the dev team as it is authored.
The result is, the dev teams get information in sub-flow sized chunks, but because they have all of the high-level storyboards and wireframes, they understand clearly how each sub-flow will integrate into the overall app, so we don't have to wait until all the screens are designed and they can start coding immediately and also provide feedback immediately.
I finish everything and only then pass it to the programmers.
Usually the best is to use some kind of mock-up software (axure, invision, flinto, etc.) So they understand the entire usability.
This is even more important in work with clients. Only after the client approves the design we pass it forward to the programmers, and then it comes back to design for QA.