Clients and mockups

Question

I tend to define a mockup as a functional analysis made fancy by wrapping a visual coat around it so everybody can understand the logic and structure featured in the proposal.

For us (UX, IxD, designers, developers, industry professionals...) it's a clear and understandable document shaping the foundation of the flow, so it is important to get the client to understand (and approve) it. This is where I tend to experience some 'problems'. Some clients (certainly not all of them!) interpret mockups as a design proposal and instead of approving functional features they often comment on placement, design and even the dummy text... yes, they do.

Whenever we can we also create a provisional design (in support of the mockup), but in most of the cases the lack of feedback (and time) doesn't allow the creation of a graphic counterpart.

How do you people avoid this problem?

Answer 1

I employ a technique I call "MVW" Minimum Viable Wireframes : Put the least amount of effort into the wireframe that conveys the design and purpose to it's intended audience.

If a napkin sketch gets the point across, great.

If it's a whiteboard sketch that you and the developer make together and take a picture of, go with it. (My favorite)

Both of these work for internal exchanges

There are definite needs for more fleshed out mock-ups. In this case I always tone them down. Explaining their conceptual nature never works.

I use balsamic since the sketchy nature helps people intuitively understand their purpose. Plus it's easy to use. You can switch the font and wire skin to be line based and system font. The look more high fidelity.

When I am updating an existing feature, I sometimes work in Photoshop with screen shots. This produces high fidelity mock-ups that regularly burn me! People get bogged down in the design vs. the concept. Or worse, the translate them identically when I only meant to convey an idea.

Ultimately, we are in the business of producing engaging applications, not wireframes and designs. I feel spending too much time on them distracts us from the many other aspects of a UX designer's job that are so important.

Answer 2

This may sound funny but I am not joking...

Make crummy looking mockups.

Find some design software that lets you render your ideas as imitation pencil-drawings, preferably one with multiple-colored pencils available. Use that software to render any UI elements and dummy text in pale grays, so that they are clearly inferior to the Clean Bold Dark Type which you use to describe the functionality and to illustrate screen flow.

In essence, use your design skills on the mockup itself, to focus your customer's attention where you want it. Don't waste a lot of time making your mockups beautiful... but do invest some time in your mockups (and in everything else you produce) in making them focused and purposeful.

Answer 3

I agree with Henry, and can suggest one of those apps that make roughish looking wireframes: Balsamiq. It creates a sketch-style mockup which when needed, can be reproduced as a finished wireframe.

I don't use it (I use OmniGraffle) but have considered switching over because of clients sometimes seeing the loose WF as the definitive design.

Here's the link: https://balsamiq.com

Mike Side note: I had to add a response instead of commenting because I don't have enough cred.

Answer 4

In a nutshell, wireframes are like baby shoes. Don't put too much expense into them because they'll be grown out of before you know it.

Answer 5

What i do is descibe every element on its own, and include the mockup of that particular part. So the section can be named "homepage elements" then one part would be: introduction carousel... then a screen shot of that element alone is added. Refrain from adding colors, use lorem ipsums, and use wired boxes instead of shaded ones, it gives the feeling of a blueprint.

At the end of the day you will get the wrong feedback. You can do two things: first, guide your clients on the kind of feedback you are looking for, like saying: positions and sizes of elements are not decided yet. Then, channel their feedback, put the ones that don't matter aside for later stages, then clearly state, that their notes will be considered in the following stage. If you completely dump their irrelevent feedback, they won't notice because we all know the second phase would look 180 degrees different.