Perhaps the most common question after “How are you?” in any context is “So, what do you do for a living?” If you’re a UX designer, answering that will get complicated quickly. Because, even though the field has been around for a while now, many people - even those working in IT - still aren’t sure what exactly UX is.
Anyone working in this field for any significant amount of time would have the “off-the shelf” answer that doesn’t turn into a 5-minute soapbox moment where we explain what UX is and why it matters (so much!!). My answer is “it’s kind of like engaging an architect for a house, I create a blueprint for web apps that tells everyone where everything needs to go. And then I talk to people about it”. That answer is usually plenty complicated to yield some confused looks.
Sometimes, however, I do need to explain more. And when I do, I focus on describing the most important deliverable along with the validation process: rapid prototyping and usability testing.
So, What is a (clickable) Rapid Prototype for a Web-or Mobile App?
In the simplest terms, a rapid prototype is a (relatively) quick mockup of the user-facing areas of a piece of software. It looks kind of like this:
A rapid prototype like the screen above (except clickable, too) is built based on the requirements from the customers; their business needs and findings of initial user research. It’s very much a collaborative and iterative process, so it typically goes through various stages, each being slightly more detailed than the one preceding it. It’s not pretty, but there’s a reason for that which I’ll get to a bit later.
The goal of a prototype like this is that it allows you to click from screen to screen and navigate the most common paths through the system. Let’s say you’re building a classifieds site. In that case, you might have a login screen with a submit button, then another screen where you can add a new item, then another where you see and search all the items added by other people. You can see what filtering options you have, what information you see about the listing before you click through to the detail page and finally, once you’re on the detail page, how you contact the seller.
Anyone from the team can do this - click around and get the same expectations around functionality - but more importantly, the prototype can be tested with real users and adjusted accordingly.
It’s Not the End Product
How does this differ from the end product, you may wonder? If it acts like the end product then surely it can become the end product too?
Short answer: no. The rapid prototypes UX designers create are static - they don’t have the smarts that a final software product would. They aren’t capable of holding information about a user account, maintaining a database of products and then searching through that to serve relevant results, etc. Yes, it is theoretically possible to prototype in a way that can be reused for some elements of the end product, but it’s a lot more time-consuming and ultimately doesn’t benefit the project in the long run. The whole point of prototyping it first is to spot any issues before a significantly more costly and time-consuming effort (development) starts.
It’s not Webdesign, Either
Okay, so what about the look and feel? This doesn’t look like anything I’ve seen on the web in the past decade. This part is spot-on, and it is deliberate too. When building a rapid prototype, we are focused on the functionality - the interaction, the journey from page to page, the information architecture. Do users know where to click if they want to browse the site’s offering? Do they get confused by certain things, such as a button or a label? Do they wonder about where to log in or perform any other core function within the app?
The prototype’s design - look and feel, fonts, colours, images - are kept to a minimum to allow for these conversations. The conversation about fonts, colours, branding etc. is just as important and will influence the overall experience users will have with the app, but that will come later, once we’ve clearly established what we’re trying to achieve and how we want it to behave.
Why Prototype?
I’m hoping by this point it’s fairly clear what the advantages are, but to summarise:
- distill the requirements into a clear format that transmits the same message to all the parties involved, regardless of their technical know-how or software project experience
- de-risk the solution by testing it first with end-users, ensuring that you’re building something that adds value to their life and improves whatever their current solution is to the problem you’re trying to solve
- focus on the functionality without being distracted by discussions around aesthetics and branding And lastly, is it worth it? I might be biased here, but I certainly think so. Prototyping is obviously not free, but we’ve found it more than pays for itself during the course of development.
