For a long time wireframes – the images setting out the functional elements of a web page ahead of design – have been a standard part of the process of creating a new website or app. They are often scoped in as a deliverable to be signed off before the graft of coding something comes into play. But as projects become more agile with design iterative in the build, a milestone single-output wireframe can become a bottleneck between user research and interface design while encouraging projects to rely on opinion instead of behavioural insights.
Along with changes to the way we deliver digital projects wireframing is changing, and has become like the overall design process more iterative. The traditional wireframe – greyscale boxes to act as a grid for the designer or front-end developer or to solicit the opinion of stakeholders before commitment to build is made – are less useful than they once were. Indeed, if your build relies this heavily on the opinion of your stakeholders you probably need to reverse from wireframing and have another look at shaping the digital service and the project from a user needs and behaviour perspective.
Assuming you’ve got those user needs nailed it’s worth looking at the skills in your team, where they sit and how to move forward at pace. Whether there is a dedicated user experience designer, and whether that is the same person as is designing the interface, working collaboratively on interactive prototypes is likely to yield better insight than a grid-wireframe alone. However, those early sketch layouts are still great conversation starters within teams and to start to visualise concepts for non-digital players – pitch them as fluid rather than old school output and they very much have a place.
I’ve found I now tend to go through a few stages of wireframing during a digital build and rather than looking for one milestone output with a stop/go sign off, I look to create a series of outputs to feed into an iterative user experience and interface design process. Here’s how I wireframe now and some of the tools I (and the team around me) use to do so…
Paper prototypes and digital sketches
I tend to use sketches (on paper) to start visualising layouts and flow, often using sticky note sessions and results of tests like card sorts to feed into this. A sticky note wireframe can still be really useful in developing a navigation hierarchy or broader information architecture. These are great tools to talk around as a team in order to understand user research and challenge our assumptions while starting to build concepts for the next phase of wireframing. This work is low-cost and can be really quick – sketches can be lo-fi and it’s the capturing of the understanding and questions which is the important part.
Interactive wireframes with real content
Rather than look to develop grid layouts (although I still use Balsamiq occasionally to convert my paper sketches to a digital format) I’ve found myself working more with interface designers to take the results of user research and paper prototyping and create interactive wireframes. It’s at this point I bring in real content – even if it’s draft it’s by far preferable to Lorum Ipsum. I don’t want to ask users to imagine what they would do, nor to utter the words ‘that’s just placeholder content’ to try and steady a bemused stakeholder. I want to start to show them what the digital service might look like, and allow them to click about on it so they can see how it feels and I can see how it works (or doesn’t). I really like InVision for this stage, and found it particularly where teams are working remotely.
Working prototypes
There is often a difference between what people say they’d do, or what they’d like to feature, and what they really do when online. The best testing is to see real users in real action and early in the design process a key way to do this is through working prototypes, which can be used for remote testing or lab-based observation (although this too adds an artificial element which may have a small impact). An iteration of the interactive wireframe the working prototype begins to bring in front-end development to give some areas of the design functionality (even at a lo-fi level) so users feel they are in a real (if sparsely populated) digital service and I can see not just how the interface works, but how flow works in a process too. There’s a blog post here (by Carl Bembridge, now of Include Creative but then in-house at the council) about how we created three prototypes based on different interface design concepts as part of the Digital First project, and how understanding behaviour and considering (but not relying) on opinion from these helped us to move forward to an initial design for our beta site. The concepts began to bring the project to life and led to more engaged stakeholders, set new thinking off within the delivery team and – most importantly – allowed us to do in-depth and vital testing with real users.
The skills and learning from the process of wireframing are still valuable in designing digital services and products but like other parts of design and delivery is evolving, and should now be iterative in visualising research and feeding into new versions to test with users. With more tools around that make it easy to share designs and put together working prototypes there’s little reason to rely on greyscale grids or print-outs for stakeholder comment in order to tick the wireframing box.
~
I’m a freelance digital content strategist offering services across transformation, leadership, digital content delivery and training, all tailored to your needs and budget. See how we could work together and get in touch.