UI Prototypes as Requirements can cause budget overruns and hurt Usability

UI Prototypes as Requirements can cause budget overruns and hurt Usability

Creating great software requirements is very challenging, and we are always looking for better ways to do this, as most project issues stem back to poorly defined requirements.

Creating UI Prototypes is certainly one method our industry has adopted to define requirements. For clarity, when I refer to a UI Prototype, this is not static wireframes, but in fact a fully interactive user interface that looks, feels and interacts like the finished product with detailed interactions and sample data.  In contrast a UI Wireframe or UI Storyboard of Wireframes is not something I would refer to as a UI Prototype. They are great at getting stakeholders excited about what the product may look and feel like, as they can interact with the prototype. They are also great at exploring usability design concepts that are new in concept and require someone to experience it via a prototype to fully understand it and see if it is the right way to go.

Having said that….here’s the bad news about UI Prototypes

If ALL you do is create a UI Prototype, you have just increased the risk of your project being over budget, as UI Prototypes do not capture enough details about requirements.


  1. Additional Contextual Requirements Details are more easily added in a UI Wireframe:
    1. In Contrast, with UI Wireframe (low and high fidelity) tools you can add important additional requirements in the form of additional text/comments and have arrows pointing to specific areas of the UI Mockup.
  2. Reviewers must “discover” the user interaction flows within a Prototype
    1. When you give your beautiful prototype to someone and they are asked to review it to understand the implied requirements, they need to start randomly clicking on things to find out what the prototype does.
    2. This leads to the very real possibility of the reviewer missing critical user interaction flows or interaction details within the prototype.


Creating UI prototypes can actually hurt your Usability Design


  1. Creating a UI prototype even with the best prototyping tools out there, takes more time to create than creating UI Wireframes (high or low fidelity). When creating UI Prototypes, you end up spending time creating interaction functionality, sample data functionality, flow functionality, which all takes time to code within even today’s best UI Prototyping environments.
  2. When something takes more time to produce, the authors become too emotionally attached to their work and as a result become more defensive and unwilling to explore completely different design directions. This is what can hurt the usability design of your software.
  3. Also, in order for these prototyping tools to actually interact like real applications, they end up creating a library of ui controls with a look and behavior. This sounds great…but, this can often limit your design to the UI controls that ship with the product. Some products do have the ability to add interactive UI controls, but this is typically not easy to do. In contrast using a drawing tool like PowerPoint you are not limited in terms of the creative user experience ideas or UI controls.

A Better alternative:  Wireframes, Storyboards, Use Case Storyboards.

  1. Using UI Wireframes are better because you can iterate through them more quickly than full blown prototypes and thus better explore the ui/ux design options
  2. Use case storyboards are a great way to link your wireframes together in the context of a use case helping clarify your requirements even more than just wireframes can do.

If you must create UI Prototypes – consider using actual developer tools

  • If you are going to create a full blown UI prototype with detailed interactions, sample data, then consider using actual developer tools.  Using developer tools you can still be very productive when creating UI Prototypes and you also will better understand the limitations of the tool suite you use and how they impact the design.  In addition, all though many of the UI Prototyping tools out there will say they product HTML which can be used by your developers, if you talk to any developers they will tell you to throw that code away, because it is typically based on a different technology toolset than what the developers will use.

Leave a reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>