Killing the page – Part 2/3: the broken analog toolbox.
Why wireframes, content, prototypes, design and front-end code do not work as separate deliverables.
A year ago, during some of our larger-scale projects we realised that wireframes, content, prototypes, design, and front-end code are not the silver bullet delivery. On the contrary, it can be a nightmare for a team to keep them all up to date and relevant.
Our analog toolbox.
Let’s first outline our previous setup and quickly go through how we thought that we could steer through a project from initial research to the final push to the live server.
1. We always start with a research phase where we get to know the user, our client, and both their needs and problems.
We use pen, paper, and Omnigraffle or Balsamiq to create the wireframes, and wireframes have mostly been produced as flat and static pages.
2. The wireframes are accompanied by static step-by-step annotations where the user interactions are described in more detail.
3. We also produce some rough prototypes for user testing.
We’ve fallen in love with Invisionapp.com for that functionality since they have a simple, intuitive interface and Dropbox-like sync for collaboration on the prototypes. Alternatively, we use Axure to create interactive prototypes. But since prototypes are built separately from the wireframes and in isolated tools or services they mostly get thrown away after user testing.
4. Next, we start up the visual design.
We’ve abandoned Photoshop in favor of Sketch, since more and more, we’re using .svg:s for the graphics.
5. After that, the front-end kicks in.
By and large, it lives on the front-ender’s local host/laptop until a few weeks into the front-end phase. Then it’s checked in to the TFS and the development server.
The nightmare sneaks up on you.
The process described above is pretty straight forward, except in that it sometimes leaves us with a pretty tall pile of disparate files. Add one or two more stacks by having all the pages/files in one, two, or three widths to cover the narrow, medium, and wide responsive versions.
Wireframes, in all their glory, cannot illustrate interactions without having to spend a large amount of time and money on creating an exhaustive amount explaining the states and flows of the interactions.
The client understands the purpose of wireframes, but the most valueble feedback happens when stuff starts to appear in the browser.
And no matter how many wireframes you make, the most valuable feedback happens when things start to appear in the browser. This is simply because actually interacting with objects on a smartphone or screen is completely different from looking at them and having the interactions explained to you.
What happens, then, is that you revise interactions, flows, structure and the like in the front-end development phase. Additions are made in the different sprints, functionality is re-prioritised, and things are taken out of the project.
As a result, you create a very disjointed work process and are you’re left with out-of-date wireframes, prototypes and design-files stacked so high on your desk that you’d rather not look at it.
In essence you loose continuity and quality.
Based on this, we are left with two options:
1. Spend a lot of time and money going back updating all the OmniGraffle-, Balsamiq-, Photoshop-, Sketch- and prototype files in all the projects that need it …
or …
2. Rework our whole project toolbox.
Read more from Nansen on our blog
Andreas Carlsson
