ArgonDigital - enterprise automation experts

Share This Post

Prototypes and Wireframes

I was recently reading Scott Sehlhorst blog post on prototypes, which is a nice discussion on the value of prototypes, but also includes some of the challenges of using them.  Scott discusses how a prototype can be an invaluable tool for a product manager for elicitation and feedback in an agile environment.  He also discusses some of the common problems with using prototypes, such as not setting the users expectations about prototypes appropriately.

This post by Scott was very timely, for the project I’m currently working on requires us to create some wireframes and move towards a prototype.  We are working with a client who has an application that needs to move from one platform to another.  As part of the migration process, the client wants to take the opportunity to make some improvements in the tool, especially around usability.

Their current tool was developed with minimal input from the end user on the UI.  While requirements were gathered, and yes the tool does do what was asked, the usability is poor, to the point that the client has isolated who uses to the tool to only a select set of people.  For others to get their data into the tool, they must go through a request process, and then the information is transcribed into the tool.

Thus, one of the deliverables for our project is to provide some wireframes and prototypes to help development understand what the business wants.  As we started this deliverable, we ran into the question of what tool to use.

Part of the challenge I have seen in the past with wireframes and prototypes is if they look too “real”, the user gets side tracked with things such as the font used, the spacing of fields, and the color of the back ground.  That is not our concern at this stage of the project, we want to be able to provide a sense of what the tool should be designed and how it would behave, not a definitive picture of exactly how the UI should appear.

In looking at various tools, we also wanted a tool that was easy for us to use, and one that produced an output that we could send to our client who did not have the same tool.  And of course, we also wanted something affordable .

The tool we chose met our requirements, especially the one about producing output that did not look too “done”.  We chose to try a product from Balsamiq.  The output mimics a hand drawing, with lines and a font that makes it looks like something that a person would have drawn on a white board or on a piece of paper.

And we appear to have achieved our goal with our first round of wireframes.  When we showed them to our client, the focus was on design…not on how it looks or if the font was correct.  To our client, it was obviously a wireframe.  Mission accomplished!  Now we just get the design right!

Prototypes and Wireframes

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage