2

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?

Improve this question
1
  • you have an open question from January that you may want to close out
    – tohster
    Mar 1, 2015 at 17:26

3 Answers 3

Reset to default
4

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.

Improve this answer
2
  • Tks, in that case, is it better for me (since I'm unsure) to ask the development team whether they want everything only when it's done or they want it part by part? Or is that asking for trouble LOL
    – Xeon
    Mar 1, 2015 at 14:51
  • 1
    Depends on their workflow — I'm pretty sure they are splitting their pipeline into sprints or dev cycles, though, so "in parts" might work better. And by all means, it's always better to ask how the other side prefers deliverables to be delivered :-) It's good team playing and good form in general, I think :-)
    – Zoe K
    Mar 2, 2015 at 16:06
2

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.

Improve this answer
2
  • Tks guys, actually, I forgot to mention, the whole UI wireframing was actually done by the dev / programming team though. That was already completed before I joined the company, so now I'm taking the wireframes and converting them to hi-fidelity mockups. Problem is : I find a lot of the layouts and flow to be kinda messy and now I've to look through the whole thing and revise it here and there before doing the hi-fi version.
    – Xeon
    Mar 2, 2015 at 15:11
  • @Xeon got it. Depending on how far along you guys are, you may want to create a storyboard map to outline how you plan to divide up the screens, and what order you plan to deliver chunks in. That may give devs a good overall context on delivery, and also allow you to deliver in chunks (and get feedback) rather than wait until all 80 are done.
    – tohster
    Mar 2, 2015 at 17:17
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.