Another view of the JS prototype

Solving customer pain point through simple prototyping and using my 20/10 rule

Prototyping is part of my work. I don’t trust product owners or analysts that do not prototype ideas and share them with the customer or another stakeholder. I will tell you more now about my strategy and I hope it can be useful for you.

I have grown the ability to listen, remember and prototype nearly live time, but since my buffer size is not so large I ask the customer to do short 30 min iterations, instead of just Q&A for 1 hour.

How does it usually work?

 

First meeting

Let’s have this imaginary situation – a customer approached me to create a very simple (from hers point of view) application to help her to run their business better. The first 20 minutes of our discussion I have been asking questions and in the next 10 I have been able to come up with an idea. After 30 minutes I had this ready – ugly, but useful

Prototype on Paper
Prototype on Paper

The customer was happy with the development, so we moved on to the next screens, again using 20+10-minute approach. At the end of the second working session, I had the full concept on paper together with a lot of notes and small indicators of interaction. (see the arrows and the kpi indicators)

 

Second meeting

I put all of these papers on a wall and I have created the first digital mock-up by using balsamiq (one of my favorite tools). I tried to make it as close to the paper version as possible spending half a day in just making it “clickable”, so I can present it later faster.

 

Digital Mock-up produced after the first meeting.
Digital Mock-up produced after the first meeting.

 

After that I had a presentation session with larger group of stakeholders (from customer’s side). In general they liked what they saw and asked when they could play with it. I told them I would give them a prototype in a week, noting that the prototype would not look like the one they saw today since the appearance would have to come come from our design team (mainly thinking about UX guys first). The agreed principles, however, would remain the same.

 

Third meeting

With all the screens and my notes I contacted our UX guys and Information architects. They gave me some advices on how to incorporate our company style, usability patterns, and UI into the prototype, using the information I have collected. The final result was smashing. I have created a small Js APP using the company framework to make a real looking prototype.

 

Part of the JS solution
Part of the JS solution
Another view of the JS prototype
Another view of the JS prototype

The customer was happy with the job we have done. I gave them the prototype to play with and we tracked their way of learning the new interfaces and their journey inside the app. We have collected useful data and that helped us a lot in developing the product.  By knowing what everyone expects I can write better tasks to the developers and will shorten my communication time with the customer and other stakeholders.

It was a huge success and I am planning to use this approach again.