If a picture is worth 1000 words, a prototype is worth 1000 meetings

I know lots of people who use software. They use it on their way to work, at their desk, after dinner and before going to sleep. I know fewer people who read about software and even fewer who read about how to use software. Kids and teens grew up in a world where things like video games come with no instructions. Most business users of software go to training and then end up back at their desks playing with applications to see ‘where stuff is’ in an application. Even my parents will just start hacking around to figure out how to do stuff on their phones or laptops.

I also know a large number of Business Analyst who understand the aforementioned, but still feel the product of interviewing Product Owners and end users has to be an artifact that has bullet points, numbered list or ‘unique identifiers’ for everything they were able to capture during the process. While the document may be very accurate, the pitfalls is that this document mostly serves as proof that the Business Analyst accomplished what they felt was their role on the team. But the pitfalls of the process are best summed up in the analogy.


All of the children in my family took the sum of two minutes to play the “Point out the differences game” with the above pictures. I point this out not to insult any of the project roles which the cartoon picture pokes fun at. I bring it up to draw attention to what is actually in the first picture and what that means to the Business Analyst. A person could write a multi-chapter novel on how to build a tree swing and it might end in the exact same result. Of the one in a hundred people who read instructions when they pull them out of a box for any product, 50% will just look through the pictures and the other 50% will refer to the instructions as a confusing junk show of directives. 

Don’t write the strategy down, make a prototype

So how do I spend my time as a Business Analyst if this is my driver’s seat take on the results of most software projects. I spend my time designing. I even tell people that my job is to design software. And for all intense purposed, I stand by this statement. Oh, sure I make a requirements document for myself, but what I produce is a prototype. I create every screen I need to deliver what was asked for by the business during my requirements gathering sessions. I never ask them to read a document and I never pass a document on to a developer. But I am the first to admit, I do not code. I create vaporware. Sounds like a bad thing, right? But think about it more and you can see where I am headed.

Vaporware in theory is a great idea. You show people screens that demonstrate things it can do before any code actually exists to do it. You get immediate feedback, good and bad. You get questions about your ability to make it do something else. The sum of all of these conversations lets you know exactly how well the solution fits the customer’s need. And this is how I spend my time on a project. I create vaporware. And the review process brings it all together.

I run meetings two times a week with the business and 3-4 times a week with developers. And they like it. They like it for the simple fact that I hardly ask them to listen to me speak. In practice, I rarely have to do anything but answer questions. The business and developers drive these meetings because I show them software. I show the developers first in a meeting that is basically ‘Can you build this?’. I get all the information I need from this meeting because developers tell me everything on their mind. They let me know if they feel there is a better way. They let me know if data about anything is not available. It’s amazing how few developers want to design UI when asked to, but how good and quick they are at it if you give them something to re-design (i.e. – fix). And I mean that. They are awesome at it. From there I spend a day and make design changes to my prototype as needed.

I pretty much do a rinse, lather and repeat with the business. I show them the prototyped screens and I ask them, ‘Will this work’? Again, the feedback is awesome. They provide me with everything I need to have in my design to get it rubber stamped. If my design changes need vetting with the developers, I check in with them. If not, I redesign and present the changes in my next business meeting to get that rubber stamp. It all goes without stating that this is a change of pace for most people. But after the first week of meetings it just seems to click for the business and developers. The business sees their application being created twice a week and the developers are shown what they are going to be asked to deliver on before it is taken to the business.

I really feel this all works based on a ‘ask permission’ principle. If the design of actual screens truly solidifies what you are asking permission for, it removes many points of confusion. The process eliminates most of the “I thought we meant something else” risks that often appear in User Acceptance testing because UAT happened in every meeting I held. The team basically delivers software that the business feels they have already seen. I have already described the changed responsibilities of the business and developers in process (which are actually minute), so what does a BA need to add to their responsibilities?

Today’s software requires modernized BA skills

In large part, modern day application development needs Business Analyst who can design. Largely due in part to the fact that software needs to be designed to deliver business capabilities. Strengthening an existing skillset based on understanding Users, data and workflow is crucial to truly understanding the aspects of the requirements gathered. You need to be rock solid in these skills to move to the role of designer. And the designer aspect mostly relies on starting down the path of learning the skillsets of a UX/UI designer. Learning the core principals used in that role helps the BA use the prototyping tools needed.

When it comes to actually building a prototype, researching about rapid prototyping and screen mock, application mocking and software UI design tooling will start you down the path of the work that needs to be done. And apply the same principles I’ve already mentioned. You don’t need to read 50 blogs and 10 books to start designing prototypes. Like they old phrase goes “Start marching!”. Feel free to talk to the developers about what they would like to code the UI in. It can help steer you towards an appropriate tool. Did I mention, most of the tools out there require no coding skills at all!

For a peek into the world of designing through prototyping try out some simple solutions…

Or take a look as some which are more specific to actual platforms your team will be working with.

iPhone/ Android / Angular


Topics: Agile, Requirements Management, Lean Startup

Written by Mark Hense

Mark is a Requirements Principal at NVISIA where he has worked for the last 6 years.

Leave a Comment