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.
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.
Multiple snapshots shown one screen at a time.
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!
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.
What’s your conclusion?
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.
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.