Wireframes vs. Prototypes: Is Balsamiq a Better Choice Over HTML?

UX Design picture of pixelated lego people building an iphone

 

Patriot Software’s lead user experience designer does a question and answer session about the merits of prototyping tools like Balsamiq versus HTML, and the role the two play in the Patriot Software development workflow.

 

Balsamiq takes a backseat to HTML in Patriot Software’s design process. @Dreger explains why.

 

Why do you prefer doing straight HTML prototypes over wireframing tools like Balsamiq?

Currently, there are two situations where we like to build prototypes: 1) when we’re preparing a demo for a user test, and 2) when we’re creating deliverables for our developers to take and implement in our online accounting and payroll solution. In both cases, we’re looking for a high level of fidelity. For us, this usually means that we go straight from whiteboards to either Sketch, Photoshop, or HTML.

Prototyping is less about the tools and more about the process. By embracing whiteboards and paper, instead of other wireframing tools like Balsamiq, I’ve found that there is a great opportunity for conversations to happen. Additionally, whiteboards and paper do not require special training, and people aren’t limited by a preset list of elements that you are confined to with wireframing tools.

However, once we’ve got the flow and general design ironed out (and photographed), proceeding straight to HTML prototyping can help us get to a finished product more quickly.

Also, since we’re always thinking about what the HTML and CSS will look like, it helps us make sure we don’t design something on paper that will be a nightmare actually to code. Empathy is not only important to have for the user experience, but for our development team as well.

Is there a place for wireframing tools?

Absolutely, but we don’t find much use for low fidelity prototyping tools like wireframes. When it comes down to wireframes vs. prototypes, we prefer the higher fidelity prototyping tools. Tools that let us create mockup animations, user flows and interaction are all great, particularly if we plan to show the designs in a user test.

Outside of user testing, sometimes you need to demonstrate a polished design to a group of stakeholders. In this situation, pictures of whiteboards probably aren’t the best medium for your message. In this situation, using Sketch, InVision, or Photoshop can let you iterate mockups on a high fidelity design in a reasonable amount of time.

Regardless of what you use, prototyping will always be a level of abstraction between the idea and the implementation. Understanding the context of what you’re working on is important.

Do you see that as a major responsibility between the UXD and the programmer?

Our responsibility is to make sure we’re handing off a set of deliverables that consider any potential state of our application. Knowing your user helps you identify what states might be more important than others, and those are the ones you need to make sure have a higher level of fidelity, so nothing gets lost in translation. UXD sits right in the middle of development, users, and the business, so we need to make sure we’re well versed in the tools and mediums of those groups.

 

, , , , , , ,

Comments are closed.