What is the best way to review static mobile mockups?

Question

This question is in regards to mobile site layouts but could just as easily apply to apps. I am not concerned with pitches, just true team reviews among UX, design, dev, and business partners.

I always prefer to review a full depth mockup as an image directly on the device where I can at least scroll around. Unfortunately, one or a series of static images on a big meeting room screen is still a required element in many scenarios. This is the format I struggle with.

I see three main options.

Full depth.
A full depth layout with the device as a backdrop anchored at the top of the page. That is to say that the mockup just runs right past the bottom of the device and continues until the content ends.

One screen.
Multiple snapshots shown one screen at a time.

Realistic.
A very literal variation on the second option where the mockup is in some sort of perspective on a photo of the device, sometimes in a users hand.

What's your conclusion?

Has anyone found the magic, one size fits all solution? How do you present your mockups and why? Convince us all to adopt your means of faking the mobile experience and dominate the dogma of mockups forever!

CLARIFICATION:
These comps are just one piece of the process: Start with data mapping, page flows, page description diagrams. Wireframes bring a sense of order and static mockups help to develop the ideas (think "paper prototypes"). A prototype is required for detailed testing.

My concern here is when it comes time to review some tight visuals (and we're not ready to prototype yet) what is the best way to fake it? And I'm not concerned with weird client preferences, just the most productive way to visualize a mobile experience.

Answer 1

If you're mocking the product up in photoshop before coding, you may as well save the image to the correct device resolution, and simply display it on the device itself.

For presenting to multiple people, it would be helpful to have some sort of display which shows multiple pages at once, especially if you only have one device to be passed around the room.

It really depends on the resources available to you, and the setting.

Answer 2

What's your conclusion?

Yes.

Meaning: All are valid, useful solutions and may you may end up using one or more of them given the particulars of each project (The client, the objectives, the development models, the testing needs, etc.)

Note that your second example, however, appears to be wireframes, not visual mock-ups. Which is important too.

Has anyone found the magic, one size fits all solution?

Since no two clients and no two projects are ever the same, alas, no.

How do you present your mockups and why?

My ideal model:

• "napkin sketch" wireframes (boxes and arrows): Rough, simple and meant to pin down core functionality and overall site/app flow.

• interactive wireframes: sample code, or HTML/CSS or something like Axure (hi fidelity prototyping). This helps refine the above and start focus on interaction design and content needs.

• High fidelity mock-up: this may be actual screen designs mocked up in the ways you outline. It may be just one screen. It may even just be a style guide showing buttons and headers and such independent of a particular screen.

Ultimately, the goal, IMHO, is to make sure you aren't 'blinding' the client with high-fidelity visuals too soon in the process. Once you do, all focus will go to color palettes and logo sizing. So save that for closer to the end of the process rather than the beginning.

Convince us all to adopt your means of faking the mobile experience

I'd strongly suggest to avoid 'faking' whenever possible. A web site/app is interactive. There are so many details in the touches and swipes and animations and scrolls and content and etc that static mockups are always going to be inherently 'dishonest' as they will put more focus on visuals than anything else. Sometimes that's OK, and sometimes that's necessary, but just keep in mind the drawbacks at al times.

UPDATE:

Based on your addendum, I'd say "it doesn't matter". Since this is but one small slice of your overall workflow/process, I'd say it's really one of the less important ones. Mock it up in whatever way is most convenient for you. Since you are handling wireframing and prototyping elsewhere, your goal here is really just visuals, which could be simply done via screen shots or PDFs.

Answer 3

Well the mockup used depends on solely the amount of content you want to display. If it is a client pitch for an app I would not hesitate or look twice about using the second mockup. If its for a portfolio I would lean more towards the third. The first photo style I have never found usable and I feel if the device isn't extended as well than it is useless and the delivery of the image is flawed.

To extend further in regards to the second image, I would even offer a single row with the logo, color palette, and any other features such as icons at full screen device size to add character and a theme to the mockup layout.

Another option that could be possible is why not make a demo reel? I've seen many people make a gif file of the home page. I've seen some that are pitching a development with the client have a presentation board 36" x 24" of the second image mockup and a video playing on a projector screen showing how the app functions.