Today we are going to talk about Prototyping, a popular concept used not only in web design but also in software development. So, feel free to contribute or ask questions in the comment section.
Prototyping, as a concept, has been around since before the Internet. Typically, people developing a new physical product would first build the thing, and make sure that it worked as intended. The first version would be patented, perhaps, and shown to potential investors. If the inventor had access to their own means of manufacture (if they worked in an existing company, for example), they’d just go right ahead and work out the bugs until they had a production-ready model.
Remember those old demo disks? You know, the ones that came with programs with limited functionality, or the first level or two in a game? Prototypes are a lot like those demos, only even simpler.
“You build a prototype of a website or app to make sure that the concept will work as intended”
Their purpose is not so much to get prospective customers to buy a product, as to help you make a better one. You build a prototype of a website or app to make sure that the concept will work as intended. You also use it to show your clients, or potential investors, how it’s supposed to work.
Recently, we’ve been seeing a lot of apps geared toward building prototypes for the web, and for mobile apps as well. Now, Adobe Experience Designer has been released, combining the functionality of a web-and-mobile-specific “design app” with that of a prototyping app. Given Adobe’s reputation, and their market share in the professional sector, it stands to reason that a lot of people who have not done a lot of prototyping in the past might now take that step.
So, like most other ultimate guides, this one is for beginners. It’s for people who are just starting to build prototypes on a regular basis, whatever their previous experience (or lack thereof) in the design industry.
In this guide, we’ve tried to cover the basic principles above all. After that, there are links to guides with further information, and, of course, a big long list of apps and tools that you can work with.
Now, a designer who’s been around for a while has probably already worked with wireframes, and/or designed mockups in some image editor. Are these not prototypes?
Nope. Not always, anyway.
The problem with wireframes and static mockups is that they are…well…static. There is a lot of information that they simply cannot convey about the functionality of a thing. This can lead to misconceptions in the minds of clients, or even your developers, about how the thing is supposed to work. For this reason, prototypes are usually interactive in some way.
The most common exceptions are conceptual prototypes, and exceptionally well-documented static prototypes. What makes the difference is not interactivity itself, but the conveyance of information about a product’s intended functionality.
That said, wireframes and mockups are often used in making prototypes, so no one is abandoning them.
Whenever you need to show how something is supposed to work. That’s it.
The obvious example is that of a web or mobile app. Apps tend to have a fair bit of functionality that may not be easily seen or deduced from a mockup. However, even fairly static, content-driven websites may require a prototype.
For one thing, I’ve had clients look at mockups for a simple business site and ask “Okay, so if they click on those things at the top, ’About Us’, ’Services’, and stuff, that takes them to other pages?”, or “When they click send on the contact form, I get an email?”
“Even simple…tasks are often fraught with uncertainty…prototypes can help take out some of the guesswork”
Even simple browsing tasks are often fraught with uncertainty to some users, and prospective clients, so prototypes can help take out some of the guesswork from the sign-off process.
Additionally, they’re always useful in user testing. After all, if you’re going to do user testing at all, it’s best to start with an early preview of the project. The last thing you want is to have to make big changes after most of the work has already been done.
Before you start prototyping, you’ll want to determine what kind you’ll want to use. You can always use more than one kind in any given project; most designers do, at some point.
The kind of prototype that you choose will need to be right for you, your client, the project, and even the specific stage of the project that you’re in. Now, that might sound complex, but it’s really not that bad.
Each of these are intended to be used at different stages in the design phase. The rest is up to your preference, and how good your client is at understanding abstract visuals.
Clients who are less experienced with modern design processes might expect to see something that looks more “polished” so they can tell you to make the logo bigger, move that line an inch to the left, and that their site won’t be in Latin, so could you put some English in please?
If you have trouble with that, more detailed prototypes—and a lot of coffee—are your best bet. If not, then you can use something a bit more vague, and focus on mocking up the intended functionality.
These often don’t look anything like the finished product in any way shape or form. With conceptual prototypes, the details and layout of the interface don’t matter. Theonly things you’re working on are interactions and processes.
The goal of any prototype is to show how something works, or will work. In that sense, this is prototyping in its purest form. It’s literally all about the function, and form doesn’t even come into it.
They can look like just about anything, at this stage. You can use a flow-chart, post-it notes, a PowerPoint presentation, a video explaining the process with crude icon-based illustrations, or a recording of yourself speaking into the camera and flailing your arms wildly. Anything that gets the point across will do.
Conceptual prototypes are typically used at the very earliest stage of any project. Your project may not even have a name. It’s just an idea for an app or a web site, and you’ll be saying things like: “Yeah, I think it should sort of work like this…”
Low-fi prototypes are where you start to include things like the layout and screen size, and other more tangible concerns. They are typically made fast, and discarded faster.
They are intended to provide the fastest possible way to iterate your ideas until you and/or your client are happy with the basics. So don’t get attached. Most of these won’t be around long, and that’s a good thing.
As previously mentioned, the term “low-fidelity prototypes” is often interchangeable with “wireframes”. Indeed, this stage often takes place on paper.
When it’s done in an app, it’s advisable to use one that has basic prototyping functions like linking to other screens, annotation, etc. Wireframing apps do have the advantage of enabling easier collaboration over the Internet, but they’re often a bit slower to use.
These are also used at the beginning of a project, but you probably have a business model and an idea for a name by now. It’s time to sort through the myriad ideas floating around your head, and iterate until you have something that you’re pretty sure will work.
Sometimes a low-fidelity prototype just won’t get the point across well enough, and a high-fidelity is too much work for the moment. Maybe you haven’t completely refined the style guide, or not all of your graphical assets have been made yet.
In any case, this is the kind of prototype you can use in the beginning-to-middle of the design phase. They’re often made with prototyping apps, which make heavy use of simulated interaction. They can also be built with HTML and CSS, usually with the help of a CSS framework.
Yup, Bootstrap and Foundation are probably two of the biggest prototyping tools out there right now.
You should use branded imagery for these if you have it, but stock images will do. Stock UI elements are typically used to build out the simulated interface faster. Many prototyping apps come with libraries of these elements to make your work faster.
These kinds of prototypes are great for the more literal thinkers who need to see a close-ish approximation of how it will look and work. It’s easier for them to ignore a header that’s “not finished yet”, than a sketchy-looking shape that doesn’t look anything like a website header as they know it.
For these clients, you might want to wireframe out your ideas fast, and never show those to the client. Then make a medium-fidelity prototype that makes it easier for them to see where you’re going.
Well, we’re here. And so is your project. You have your mockups for every screen, and everything looks great. It’s time to show people how this is going to work, in all of its glory, when someone finally integrates it with the back-end code.
High-fidelity prototypes are usually used for getting a final sign-off on the design from the client. But you can’t just send them the PSDs. This stuff has to be interactive.
This is typically accomplished in one of two ways. Some use static HTML and CSS to put the finalized visuals together in a way that’s semi-interactive. Others use apps that import images, or even raw PSD files, and add pseudo-interactive features to mimic the final functionality of the app.
Depending on the app, you can even demo these prototypes on the web (or on a mobile device, if you’ve been working on an app).
Now that we’ve gone over the main kinds of prototypes you can make, it’s time to cover the tools used to make them. I mentioned most of these in the previous section, and their basic usage; but I’d like to go into a bit more detail.
Again, the method you choose should depend on what both you and the client are comfortable with.
These are often made to sell an idea before any concrete work has been done. Thus, they’re usually directed at potential investors. They can be used for clients too; but there are often more efficient ways of communicating with a client. Your mileage may vary.
The video and presentation-based prototypes that are made for sales pitches usually follow a commercial-style formula:
Some of these prototypes just use icons, text, and illustrations. Others have animation; and still others use live action to get the point across. And that’s, well… the point. As long as you sell your idea, you’ve done it right.
Here’s an awesome example that mixes video prototyping with paper prototyping.
Wireframes can be done on paper or in apps. They are nearly always considered low-fidelity prototypes, though they can be upgraded to medium-fidelity if you put enough time into them. It’s rarely worth the effort, though.
Usually, wireframes are designed to be both drawn and discarded quickly. This is one of the things that makes drawing them on paper so attractive. Apps can be far more precise, and you can easily edit existing wireframes; but nothing beats the speed of a sketch that no one is supposed to see but yourself… ever.
However, as previously mentioned, App-based wireframes do have the advantage of more easily mimicking the functionality of an interface. Tapping on a paper wire-frame will just make a pleasant thunk-thunk-thunk sound.
That can be fun, but it may not convey your meaning.
You might choose to use both: paper to nail down the most basic concepts, and an app to flesh it out, and share it easily.
These differ from wireframes in that they are a lot more than drawings. In this kind of prototype, paper is used to make a physical, if still rather flat, model of the interface. You can see one of these in the video above.
Interface elements are usually drawn, cut out, sometimes copied to make extras, and then assembled on another piece of paper. This gives them the advantage of flexibility. Where you might throw away an entire sheet of paper with a wireframe, you can just re-arrange the elements of a paper model until you’re satisfied. Got an element that’s the wrong size, after you’ve re-arranged things a few times? Just cut a new version out.
They also tend to feel a bit more “real” than a wire-frame. Even though nothing interesting will happen, a client can touch a paper model. They can feel it. That tactile sensation can sometimes explain more to a client than anything you could ever show them.
Everyone needs physical contact to achieve a better understanding of any object. Half of UX design is about re-creating the feeling of physical interaction with a digital interface.
These have a lot in common with paper prototypes. Prototypes made with an app like Invision, or one of the many other options out there (see the list below), are typically made from pre-designed interface elements, and then pieced together to mimic the final product.
The difference is, of course, that everything is done on the screen. Oh, and you can do it with the final graphics and branding, making the prototype look exactly like the finished product. Then, as I mentioned earlier, some apps can demo the product in the browser and on mobile devices.
This brings the tactile feeling back into play, and you want this. If you can give your clients that feeling, and they like it, you’ve basically gotten their final approval.
Of course, if interaction is what you want, then building interface prototypes with code is a good way to get it. Now, you might choose code-based prototypes for one of several reasons:
Prototyping in the browser can be a bit slower, especially if major revisions are still being made. I would not recommend it for the early stages of a project, so it’s best for medium-to-high fidelity prototypes.
Still, it’s one of the best ways to show off a nearly-finished project, if you already like to work with HTML and CSS.
Prototyping with frameworks
It should be noted that using a framework to build prototypes can speed up code-based prototyping considerably. As a bonus, if you use the framework that is intended to be used for the final product, there’s less coding to do overall.
As a side note, some people have built drag ’n’ drop web page editors based on more popular frameworks, like Bootstrap and Foundation. Using these, once could conceivably create everything from the low-fidelity prototypes to the final product with code.
However, some people just use them to build prototypes fast, and then use custom code for the final project. It works either way.
I hope you learned a something new via this article? Do not hesistate to leave comments in the comment box, your contributions is highly regarded.