Thread by @SirPsychoHelo

Alright, let’s talk about Prototyping! #MerryUXMas For the sake of this thread, let me make a quick disclaimer first

Two days ago I said that prototyping and testing are two intricate processes and that one can’t go without the other. However, I want to give you two separate threads so let’s just all remember that they are not separate processes

Also, prototyping means a lot of different things given the nature of the product you’re working on. In this case, I’m going to focus on web products, because that’s what I know best

Now that’s out of the way, let’s discuss prototyping

The other day I talked about Low Fidelity and High Fidelity products. Low Fidelity products are usually the first prototypes you’re going to make. The idea here is not to test shapes, colors, please of use, but the basic architecture and navigation

I recommend that you first establish a use case scenario: your user wants to go from state A to state B, what are the sequence of actions they need to do? What information do they need?

By doing that, you’ll have a clear idea of what you need to provide to users, both in terms of information display and navigation. Once you have this use case, you can start doing flowcharts

Flowcharts are basically a representation of the architecture of your website, what leads to where, etc. You’ll be able to list all the screens of your website and outline their relationships to each other. Once that’s done, you can start working on wireframes!

Wireframes are the blueprint of your product. They only display the basic layout of the screen and how you can interact with it (pressing buttons, etc.). The cool thing here is you can start by doing paper prototypes, and it’s pretty easy to do

Take one piece of paper and draw the baseline of the screen (like an empty header and empty blocks inside the screen). Then, take smaller pieces of paper and draw the different types of information you’re going to display (buttons, a chunk of text, an image, a scroll bar, etc.)

Now, take your use case and flowchart and create the different screens according to the steps you’ve outlined. Take a picture of your wireframe after each step (don’t forget conditions as well)

And there you have it: a fully playable paper prototype. Basically, you’ll test the paper wireframes with users, they’ll pretend to click or tap on something, and you’ll change the paper based on the effect of the interaction

There are of course easy ways to do this with digital softwares as well, depending on your level of skills with them. But I’d say you don’t have to use them at first

The idea that I’m trying to convey here is: don’t spend too much time creating early prototypes. Chances are, you’ll throw 90% of it away, so trust me, it’ll save you some valuable time later

The further you go into the whole “prototyping-testing” iteration loop, the higher the level of fidelity. For example, once you’ve secured the basic actions and information you need to display and where on the screen, you can start thinking about the more UI part of it

At that point you’ll start to test shapes, colors, fonts, etc. and analyze what works for users and what doesn’t ; until you get your final product

That’s all for today (I try to limit the amount of time I’m spending on these threads). Tomorrow, I’ll talk about testing your prototype and getting feedback to improve your product.

In the meantime, you can read this cool article about wireframing: experienceux.co.uk/faqs/what-is-w…

Have a nice day and see you tomorrow for entry 10 of #MerryUXMas