Jeremy Keith on mock-ups:
Here’s my take, is that there’s just three reasons a
One is that it’s for
buy-in, it’s basically for sign-off. You’re mocking something up to present it to a decision-maker who then says thumbs up or thumbs down, so that’s this decision-making thing, I guess what Dan could be talking about, deciding in the mock-up. That’s use number one.
Use number two is it’s a deliverable for a front end developer, so in other words they’re something a visual designer gives to a front end developer to get turned into code, so that’s a separate use-case.
Then there’s a third use of aJeremy Keith, Episode 12 of Style Guide Podcast
mock-up, which is for a visual designer to think. They have a tool that they’re comfortable with, like Photoshop, Sketch, Illustrator, whatever and it’s the fastest way for them to get ideas down is to create a mock-up.
In the responsive web projects, creating mock-ups is very time consuming. For deciding the visual design directions we utilize style tiles or visual inventory methods. Coming to the second use case – for handing over design – the problem with mock-ups Jeremy elaborate as:
Now here’s problem number one, is that mock-ups made for the first use-case end up getting used for the second. So, if you’re designing for sign-off, everything’s perfect: everything lines up at the top and the bottom, it’s exactly the right amount… everything looks beautiful. It’s not a real test of the edge cases of content. And unless you then make further mock-ups that are more accurate and reflect the real situation with content and you just hand over this perfect situation to developers, well, everyone’s just going to get disappointed: the developers are going to be frustrated because it’s not accurate, the designer’s frustrated because, hey, that doesn’t look like myJeremy Keith, Episode 12 of Style Guide Podcast
mock-up, and the client is frustrated because that doesn’t look like what they were presented with.
I only recommend using mock-ups for the third use case.