Scene 1

FADE IN:
INT. STANDARD OFFICE BUILDING, GRAY CUBE WITH A DESK AND TWO CHAIRS.
A generic developer-type character is speaking with a generic client-type person.

Developer: “So what do you want it to do?”

Client: “Oh, it’s just a simple app to help people manage their beanie baby collection. You know, see all of them and share them and stuff. I was thinking it should be kinda purple, and this article in Forbes said we should use a HPM stack and…”

Developer: “Okay hold on. So it should show a list of beanie babies at least. With pictures? What else?”

Client: “With pictures, obviously, and all the normal info like name and year and stuff. And..”.

Developer: “Alright, let’s just talk about the pictures. Do you want people to upload pictures, or use ones from tik-gram or something like that?”

Client: “Both of course! And the captions should be kept short.”

Developer: “Oh, so they should be able to add captions?”

Client: “Well, yeah. I didn’t think I needed to mention that.”

Developer: “No worries! We’ll have captions. Can the user edit the captions right on the list page, or should there be an admin section? Do you want full-screen pictures, or…”

Client: “Wow! There are a lot of details just about the pictures. I hadn’t really thought it out that far. Wait until we get to the sharing! I have some ideas…”

Developer: “Oh boy.”

Client: “Oh, and there needs to be a complete photo editor within the app. Would that be hard?”

And, scene.

Firstly, let’s hope this developer hasn’t signed a contract yet! More than that, let’s take this dialogue as a reminder that you can’t just wave a magic wand at an idea and expect it to execute.

Successful idea implementation begins with taking the time to think and pin down all the specific details. The earlier this step is completed, the less time and money are wasted later down the road after development has begun and changes are harder.

It seems like common sense, really, but it’s often forgotten. I have found a simple, cheap tool that can do the job, and luckily, I’m going to share it with you.

In this blog, we’ll discuss how to set up an effective Website Mockup. I’ll walk you through what to focus on and consider, how to talk with stakeholders and product owners, and a tool that you can use to actually build a Mockup.

Trust me, after this, your client will think you’re a genius.

Mind the Details

The original idea for a project, often, originates with someone who has never done the peanut butter sandwich exercise. They’re not familiar with how to best write up the requirements and instructions.

As in the dialogue, showing a list of items on a webpage sounds simple enough, right? But when you start really thinking about it, the details start mounting up…

• What fields of information are to be shown? Is it fixed data or can custom fields be added?
• What order do you show them in?
• Should it be sortable on those fields?
• Does each beanie baby have just one picture or many? Are they all the same size?
• What if you don’t have a picture?
• Can you click on a list item to get more details?
• What shows up on that page? Or is it just a popup? Or what?
• Can you search? Filter? Is there even a difference?
• Can you see a certain number of beanie babies at once, or all of them? Can you change that?
• What if you don’t have any beanie babies? What do you show then?
• What if the database is down and there’s an error?

The list could go on. Imagine adding user accounts, sharing, etc. – the number of possible events and screens quickly grows to something enormous, and every single one needs to be accounted for in the final design.

If you don’t do it now, you’ll for sure do it later – and it will be much harder.

Ask Questions

To begin sussing out all the details for a website Mockup, you need to understand the site, as well as the context the site will exist in.

If you’re lucky enough that they’ve already got wireframes and business rules spelled out, then great! Why are you even here reading this? But if not, it’s our time to shine.

The exact questions will depend on the project, but some starter ideas I try to keep in mind include:

• Why does this app exist? What problem is it really trying to solve?
• Will the requested work really accomplish this purpose or might there be a better way?
• Who is using this app? A customer? A worker? An app may have multiple audiences.
• What environment will they be using it in? At a desk? On a phone? In a factory with dusty machines?
• Will the app need to work with anything that already exists? Other apps, data sources, etc.
• Will the app be consuming or creating data? What format is it in or is that still an open question?
• If you’re taking in data in a form, what are all the fields? What format are they? Which ones are required or optional? What other validation needs to be done? How are the fields related to each other?
• If there are workflows or other sequential business processes, what are all the steps, and what are the rules for going from one to the other. Can you go back? Reset the process? Is there other data stuff going on outside the app that might affect it?
• How are errors going to be handled? What kinds of errors might occur?
• What kind of logging might be needed? Logging what happens on the site can be useful for audit purposes or troubleshooting.

Draw Pictures

Words are great, but even the old Infocom games would end up with some kind of map drawn out on a scrap of paper. The thing about the talking phase is that…

It tends to be a really slow way of communicating complex ideas.

Each person generates their own mental picture of what you’re talking about… and there’s no way to make sure they match.

What we need at this point is one picture that everyone can see and begin to agree on.

There are a lot of ways to make that happen. Whiteboards or pencil and paperwork well when you’re initially sketching out ideas, but I’ve found that those often don’t have quite enough fidelity to completely override each individual’s mental image.

On the other hand, if you shoot too far and make a pixel-perfect demo version of the site, you’ve not only wasted a bunch of time on something that will (will!) change a lot, but you’ve potentially fooled your client into thinking it’s all done, and they can leave with their pretty but non-functional website.

So, the aim is a sweet spot in between. Something quick to create and edit, doesn’t look done, but it still is “real” enough to get everyone on board.

I like to use a software design tool for this.

There are many, but I started using MockOla a while back and have been very happy with it. Compared to my previous favorite tool, a pencil (ha), it has some advantages.

• It helps you keep components aligned and sized uniformly.
• As you revise the design, you can move and remove items without ugly eraser marks.
• You can keep a history of changes you’ve made.
• On a video conference, if you’re sharing your screen, you can actually create or edit the mockup live.

This is an example of a mockup created in website MockOla. Note that the page elements are uniform and aligned, which helps it look real, but the graphic style is still sketchy. (You can even use Comic Sans as the font if you really need to drive that point home.)

I know How To Make a Website Mockup … But How Do I Make a Website Mockup?

Of course, having a tool is all well and good, and it’s easy to drag and drop little pictures onto a screen, but what all actually goes into generating a good design and website Mockup?

This article is not going to replace a course of study in UI/UX design, but it should help you get started!

The internet also has a lot of free information. One of the largest of which is the Nielsen/Norman Group, which has one of the best libraries of articles I’ve found over the years.

• If you don’t have much of a background in usability, then you’ll get a long way with a few basic guidelines:
• Keep it as simple as possible (but no simpler).
• Group and align like things.
• Don’t hide things.
• Remember, people spend most of their time on sites other than yours.

After that, it’s a matter of using the tool effectively to communicate your ideas. With MockOla, for example, I like to create a wireframe for each screen of the site, with elements more or less arranged and aligned as you want.

Remember that exact graphic design will come later. For now, it’s better to move quickly and get it just close enough to get the idea across.

Once you get familiar with all these tools, the genius part is that it’s easy enough to actually do live in front of the client or over an online meeting. Take advantage of this!

Seeing this “real” version of the idea is going to spur a lot of discussion and maybe new ideas. Here is a link to more information on how to use MockOla.

Remember all those questions back at the beginning of this post? There will be more. Just repeat the question-comment-mockup cycle until everyone is on board, and there aren’t any more nagging questions hiding somewhere. (Well, there probably still are, but they should be a lot smaller than they would have been!)

One challenge is to represent data that isn’t inherently obvious in the UI, like business rules and workflows. Rather than potentially hiding information in some separate document, I like to include it on the mockup itself. That way, it doesn’t get forgotten or overlooked. MockOla includes some tools for this, too.

Finishing Up

Now you have a website Mockup. What is that worth? Well, it’s not the product by any means. All the actual coding development still remains, but with the Mockup, you’ve set yourself up for a much easier time going forward.

• The product has been thought out in detail.
• It has been seen and approved by the customer, so (hopefully) you’ll have fewer changes down the line.
• You have a concrete design to be handed to developers.

For smaller projects, you might be able to start right away using the Mockup to code form. On larger teams, you might need to create more formal wireframes in a particular format.

The website Mockup could also be a basis for more extensive UX testing, which is way beyond the scope of this article. But, suffice it to say, more questions and more revisions.

In any case, you’ve got yourself a solid foundation to work from going forward that severely reduces the amount of confusion and rework that you’re likely to encounter later.

That can save a great deal of time and money, and I think you’ll be glad you did.

Thanks for reading, and please let me know in the comments below if you have any questions!