Prototyping Our Requirements

Why prototyping can elicit requirements early and prevent mistakes in a project.

We talk to a bunch people about what they don’t like, we document it, we talk to a bunch more people about how they can fix the things we don’t like, they do their thing, we test that the don’t do the things we didn’t like in the first place and fingers crossed, we’ve replaced our sad times with new shiny things. We repeat this cycle until the end of time and hopefully, things work out for the best.

But what if, instead of just designing the future based on what’s not currently working, we invented the future?

Hear me out… shouldn’t we be actually going to market knowing truly what it is we want and need? And wouldn’t it be great if we understood more closely what we were going to break? (because let’s be honest, most of the time we break something!)

This is prototyping territory and I like it. I like it because it can be easy, it can be simple, it can be super cheap and wait for it… it can be playful too! You can use tools as simple as a pen and paper. You could use software like simple spreadsheets or UX tools. You could even justify the business expense of Lego and ribbon! Who doesn’t want tax deductable Lego?

Absolutely do a market scan if you’re replacing a product! See what functionality is out there but facilitate stakeholders in workshops around their desired future state and see what wonderful things pop up from there.

Paper Websites

As an example, you’re working for a bank. You know you have a bad reputation for customer engagement with your website and you want to replace it. Very simple scenario – you go to a fancy schmancy design studio that will promise you the earth for a pricey sum. They’ll ask you some questions about the changes you want to make and they’ll come back with a shiny new thing. How do you know if it’s what you want though? You prototype before they put a foot in the door.

Take a piece of paper and draw your first screen. On the side, list all the things you think you should see on that screen and the draw them up there. It doesn’t have to be perfect, just make sure you add what you want and remove what you don’t. Now run through scenarios about what different customers want to do on that screen and do a sharpie dot every time you ‘click’ on that menu item. Do your menus make sense? Have you drawn the right ‘quick buttons’ where they should be? Keep iterating it until you know that screen has enough. Where you’ve got no ‘dots’, remove that item. Where you have a lot of ‘dots’, make it prominent on the screen. Recreate for the different screens until you’re comfortable you know the true value of your screens before you get your fancy designer to work on it.

Justifying Lego

My two favourite Lego prototypes were with civil engineers and solution architects.
For the Civil Engineers they used Lego to build out their ‘ideal town’ and had little characters that they ‘walked’ around the town. They were looking at improving the experience of locating pharmacies, post offices, shops etc by their public transport.

Another neat trick is building out all of your IT systems on a big table. Make a dollar sign for the Payroll system, a calculator for the Finance system, a person for the HR system etc and lay them all out. Then take some ribbon and connect the systems by sticking the ribbons between them. Now take a long look at it and say ‘if we are planning on decommissioning/replacing a system, which pieces of ribbon would be cutting or realigning?’ It’s a great way to visualise your system architecture and make you think about all of the connections before jumping into a system replacement/decommissioning project. You an also use Play Doh if you want to be super tactile to make your systems! Then you get the reminder of childhood when you smell it as it comes out of the tub.

Hopefully you can see why prototyping is a great idea for a BA in the early stages of a project to source requirements and prevent mistakes.