We rely on some of the best tools in the industry to bring our designs and user experience expertise to life. In a collaborative piece with UXPin, learn how we helped Babel Health actively engage with the prototypes we produced to solve their business problems.
Static wireframes have been a mainstay of the design industry since the dawn of the design industry. Grey boxes and blocks of "Lorem Ipsum" were an easy way to show a client where, and what type, of content would go inside their poster/brochure/annual report. For these types of printed static deliverables, wireframes worked, without fail, for years and years. Clients could reach out, pick up, and feel their product; flip through it and pretend to read the gibberish placeholder text that would soon be their final glorious deliverable. The wireframe stayed atop the mockup deliverable mountain for many moons as an easy way for clients to understand a designer's vision for a product.
When Tim Berners-Lee invented the World Wide Web in 1989, I’m sure he could not have imagined how far it would come in 30 short years. What started as a few connected computer nodes on a makeshift server has exploded into over a billion websites logging almost 36,000 Gigabytes of transferred data EACH SECOND. Early web pages were text, maybe a few pixelated images, and bright blue links to other web pages. The web was one giant choose your own adventure book of absolutely static content in a digital format. Today, the web is an ever-changing, exploding world of multimedia information presented to users on more and more complex websites; with interactions that are literally invented out of thin air. Imagine someone telling you to “swipe right” on your Nokia 3210, deposit a check with a photo from your Motorola StarTAC, or pay for groceries with your BlackBerry Pearl.
So why don’t static wireframes work anymore? Well, simply put ... the world is not a static place anymore. Everything we encounter utilizes increasingly complex interactions; and virtually every site we visit today slides, hides, shows, grows, shrinks, spins, or some combination of each. Webpages are no longer just links to other webpages, but instead are information dense, single page applications that tuck data away only to seamlessly reveal it when the user demands it. Web designers and user experience architects can no longer hand a client a stack of papers with boxes and arrows and expect that client to understand the vision for their product. Because of more robust Javascript frameworks, including the ubiquitous AngularJS, the user does not transport to a new page with each click. There is just no way a static wireframe can stand in for a journey through a single page application.
Clients need to see, touch, feel, smell, their product as it develops (ok, maybe not smell, but you get the idea). You have to show them the drop down. You have to let them click the tab to shows the new data table. You must let them expand the paragraph when they’re enticed to “Read More.” Without representing these interactions in a prototype, you cannot accurately represent the product to clients, testers and eventually end users.
Of course, a moving, working, prototype takes more time to create than a series of boxes. There’s no denying that. But the time payback comes in other ways:
- Faster client buy-in: Gone are the days of writing pages of emails going back and forth explaining complex functionality. Instead, you build the functionality and show it to them. The clients have the actual example to react to and can understand what they are approving.
- Easier testing: Your product does not need to go through a development cycle to put it in someone’s hands to test. You can send a link to a colleague or a friend and in a matter of moments, have them try out what you’re building.
- Better transparency: It’s much easier to realize you forgot a critical user path when you click somewhere and nothing happens. Prototyping forces you to make sure you have the small details right. Since it works like the end product, you’ll be in the position of the user and notice when something is wrong.
- Less lengthy requirements documentation: With a prototype, developers can see what they’re going to make. When you pass a prototype off to a developer, they can see the interaction instead of reading about it in documentation.
- Faster path to MVP: Prototypes help you notice when an app is becoming unwieldy. This helps UX architects and product owners assess what features are absolutely critical and what can wait for phase two.
For our team, the benefits of the prototyping as opposed to static wireframes outweigh any extra time spent creating them. Early and rapid prototyping helps us create much better and thoughtful products that people can actually use. LookThink made the switch over a year and a half ago and saw the benefits immediately. Since the switch, our team is more agile, more collaborative, and is able to receive more valuable feedback from everyone involved throughout the process. We don’t see ourselves going back to static wireframes anytime soon.
Teams that are prototyping, what benefits have you seen since you started?
We’ve been using UXPin as our prototyping tool of choice. They offer a full range of features to build robust working prototypes in a rapid fashion. Their commenting tool allows our clients to easily add feedback right on the prototype screen. And they support multiple devices so you can test your mobile solution right next to your desktop. If UXPin isn’t for you, there are tens of other options out there with a wide variety of complexity and learning curves.
