Well-coordinated work across teams – let’s say design and development – is a huge deal when it comes to delivering a good product on time! So, part of my job as a project manager is making sure that the assets passed from design into development are ready for implementation.

At the very heart of the process, design review is nothing complex. You should know human interface guidelines, platform restrictions, requirements and a little bit of common sense =)

Here are the common issues I often face, when reviewing design:

• Design does not incorporate all the details on features planned;
• Navigation controls are used inappropriately from the native experience point of view; or simply not intuitive;
• Assets are missing during delivery phase;
• Mockup does not look good, when populated with real user data; mockup has not been stress-tested on extreme cases.

As our teams worked together, we optimized our process to minimize adverse effects on the points above.

1. Kick-off with an interview.

When the team is excited – it shines in willingness to collaborate on building a valuable product. Once an applicant to a designer position is excited – she starts to ask questions and share her ideas. I try to understand what the candidate thinks about the project, her motivation, her past projects experience: was there an established flow when this designer had been working on a product, how did the teams collaborate.

Usually, our projects involve UX and UI designer. An iPhone UX expert knows navigation controls, their proper use, typical user flows, analytics and split testing, how to structure information elegantly and effectively. She creates prototypes and mockups for the upcoming app. UI designer provides GUI for a mock up (colors, iconsets, sizes for different resolutions).

2. Help designer to understand the product, build solid requirements

There is a timeframe for a designer to get to know the product. Have materials prepared, older designs structured (for the retrospective view), corner cases described.

The whole team was pleasantly surprised when our new UX designer asked for requirements documents and stayed knee-deep in them for a couple of days. He came up with rational and neat optimization.

We describe global functional requirements in Confluence, with obstacles, corner cases and retrospectives added to the main article. This gives a designer (and practically any new person in the team) the understanding which issues and mistakes we faced, what are the bottlenecks of particular solutions, and why we currently have an effective solution if we already do.

We describe platform-specific flows and requirements in User Stories, which also work as checklists for designers.

The one thing I want to point at again, are the corner cases. They usually fall out of scope and do not apply to typical user behavior, but may result in unpleasant experience. We brief a designer on corner cases before he starts prototyping.

3. Create checklists for mockups

There is a quite popular problem companies face: real user data doesn’t play nicely with the mockup. The design may look gorgeous and trendy and flat, but once you start populating it with longer names, venues, low quality photos, vivid photos that make overlayed text unreadable – the whole greatness falls apart. What to do here?

• Reflect min and max length for the fields in the requirements. This way designer knows what to expect from the real data.
• Prepare corner case text examples, to check how well the mockup stands against them. For example, use location named ‘Venkata Narasimha Raju vari Bahadur’ instead of ‘Union Station’. Show how long text should be cut, if needed.
• Keep in mind that if you support multiple languages, some buttons may require more space for a label to fit.
• Check for active / inactive states for buttons, segments, toolbars.
• Alerts and message boxes for whatever reason can be (connection loss, lack of space, unsaved data, …)
• Text overlays. If text overlays a picture, be sure that text is still readable even on a bright vivid photograph.

4. Wording for mockups

Wording mistakes happen quite often. You may have ‘Done’ button in current application, and ‘Save’ in an updated mockup, or even different labels for the same action in different sections. I make sure wording is correct and synced across designs, before dev team starts implementing it. Easiest path is to have all metaphors documented inside a task-tracking or wiki-system, so that designer knows how to name each element properly. This saves a lot of time and nerve for everyone involved.

5. Standardize assets delivery

In order to be sure we got all the assets we need we created a small guide on design delivery in a form of simple folder structure.

#project_folder
    - #project_iOS 
        - #comments_screen
            - comments.psd
            - #_icons
                - icon.png (for 1x)
                - icon_@2x.png (for retina)
                - icon_@3x.png (for retina HD)
                -

This hierarchy serves to ensure we have needed states and sizes for icons, and a structure that will confuse noone.

Overall, I hope that this brief article helps you optimise your process and get design delivered faster =)

Special thanks to Ksenia, Rishat, Igor for reviews =)