Not too long ago, I came across an article about the #NOPSD Movement that really resonated with me. The NoPSD Movement advocates applying practices and tools used for writing software and product development to UX creation. One quote in particular caught my attention:
We need to pivot our DESIGN.
This got me thinking about how much our deliverables rely on documentation. At DesignMap, Illustrator and Photoshop are still king and it’s not uncommon for us to produce100-plus page document in our attempt to describe complex user interactions and experiences on paper.
We were concerned that these documents, regardless of how well crafted they were, were being overlooked, ignored, or were simply out of date at production time, particularly if we were working with a very agile development team. If we took such a document and “threw it over the fence,” as the adage goes, to the client, we couldn’t really blame them for the results. Who wants to read a 100-page document when cramming for a code-complete deadline?
Final Documentation does not equal Final Product
Making the case against documents as final deliverables isn’t hard, particularly regarding UX design projects. Here are a few places where documenting interactions and user experience on paper falls far short of its goals:
- First, people don’t read. If we’re designing software, they should be interacting with a deliverable not perusing one.
- Documenting responsive design, with its multiple devices and exponential number of potential breakpoints, is incredibly complex and time-consuming.
- Static wireframes and mockups should describe a cohesive, consistent design system. Creating consistent documentation for a complex system using standard design tools takes a lot of effort, often orders of magnitude greater than that needed to create the design itself.
- Redlines…nuff said!
We should be designing our products in their intended environments.
Bottom line: We should be designing our products in their intended environments. Instead of communicating our intentions for user interaction on static paper, we should use interactive dynamic, prototypes that ARE the design.
Pivoting from Paper to Prototype
A recent project for a major health insurer offered a ripe opportunity to shift from delivering documentation to providing a prototype.
The diagram below shows our process, which included a few key decisions made early on with the intention of improving how we work internally as well as with our clients. Our first decision to use Sketch as our primary design tool, for example, offered the promise of a workflow that tied together interaction design, visual design and prototyping.
The rest of this post describes the tools we used and our approach to the project, starting first with wire framing, moving on rough prototyping and finishing with a high-fidelity prototype.
Creating Wireframes in Sketch FTW
At DesignMap we generally create wireframes in Illustrator. We even have whole blog post dedicated to a specific type of arrowhead, which should show you how seriously we take that application. But where Illustrator might be great for generating concepts quickly, it isn’t made specifically for screen-based design.
Sketch, a hybrid of vector and raster editing tools, is specifically created for designing screens and optimizes workflow around common UX tasks such as reusing common design patterns and styles. We chose Sketch because it also provided:
- a hybrid of vector and bitmap editing tools that allow interaction and visual designers to work together
- exporting features that are critical to allowing different disciplines to work easily together
- CSS output for quick creation of prototypes and front-end markup
When we started working with Sketch, we were faced with the reality of getting pixel sizes right, so creating a grid system was the first thing we tackled. We also used Sketch for visual design, which was a bit of a challenge at some points. The visual designer on this project did move to Photoshop for a portion of the project in order to ‘go wide’ and explore possible a wide range of possibilities and concepts. In the end he returned to Sketch, despite the hurdles he encountered, and was able to get ‘pixel perfect’ with his designs
From Wireframes to Prototype, Increasing Fidelity with Each Step
For our project to be successful, we felt it was important to show our work early and often. We decided that using prototypes for the next stage of UX development would support that need, allowing us to show our design intentions in action instead of describing them in lengthy documents. Not only did this approach free up big chunks of time that would have been spent annotating wireframe documents, it also allowed us to show our work more frequently because the prototype was all we needed for a client meeting. We were able to dispense with the laborious documentation process altogether.
We worked in two primary modes while prototyping. For quick validation, we used InVision to stitch wireframes together with limited voice over, creating a rough prototype of the product’s system. Going from our Sketch wireframes to the InVision prototype was a breeze. Sketch’s exporting features integrate nicely with InVision.
Designing and Prototyping Concurrently
After creating the rough prototype with InVision, we moved on to the next phase: creating a high fidelity prototype with AngularJS. Angular JS is a toolset created and maintained by Google for building dynamic views of a web-based application. It includes some specific features that made it possible for us to build a prototype for the project’s final deliverable, including
- Creates a prototype that performs as a single-page application
- Doesn’t require a ‘happy path,’ or a single path of interactions, for the prototype
- Uses HTML to define the application’s user interface
Our prototyping process closely followed the design process, allowing us to integrate updates immediately. We were inspired to adopt this approach by Brad Frost, who described working concurrently on design and prototype in a blog post. Here’s how he describes this concurrent work:
From day one, information architects and content strategists can begin organizing information, visual designers can start exploring type, color, and texture, and developers can set up tools, patterns, and components. As some point in the process, a discipline might serve more as consultant for the other disciplines, while other times they’re burning hot creating things. As time goes on, the creating/consulting role shifts, but no one is ever fully out of the picture.
In the end, our final deliverable was a fully functional prototype that was highly actionable from our client’s perspective. Delivering a prototype instead of a traditionally verbose static document allowed the client to interact with the product and understand our intention for the user experience at a much a deeper level. The prototype also provided a great tool for usability testing and it demoed much better for executives and key stakeholders
Don’t Have a Coder and Don’t Code? There are still options.
At DesignMap we were fortunate to have recently hired a front end developer to help us with prototype requests. However, there are many agencies, in-house design departments or individual contractors that don’t have the luxury to work with a dedicated front end developer. So what is a designer to do? Here’s a list of tools that can produce high fidelity prototypes with minimal to no knowledge of coding:
- Macaw.co – They tout themselves as flexible as an image editor, but writes semantic HTML and succinct CSS
- Webflow.com – Another Drag and Drop style site for creating professional responsive websites
- Adobe Muse – A turn-key solution for creating and hosting websites
- Adobe Reflow – Dedicated app to create responsive websites, meant for “designers to share their responsive design intent
- Google Web Designer – Originally meant for creating engaging HTML5 ads, GWD can also be used to create sites with the of ease of a Drag and Drop style editor
In Conclusion: A Quiet Design Revolution is in Progress
Shifting the client process from creating PDF documentation to prototypes requires a sea change both for designers and clients. A few challenges to consider before you charge forth with the prototyping flag:
- Balancing learning new tools with getting work done
- Convincing clients of the benefits over traditional deliverables
- Convincing teams that the UX design processes should be audited and changed