Capturing feedback on prototypes for Drupal

At DrupalCon Prague, I organised a BoF session (an informal gathering focusing on a certain topic) to discuss capturing feedback on prototypes from clients and generally collaborating more closely throughout the design process.

The challenge is that the client (often meaning many individuals) will almost always have a great deal of understanding about who their users are and what they want. Their input is extraordinarily valuable. However, we're not always very good at capturing it in the right way, at the right time, from the right people.

BoF attendees had similar stories and difficulties, and agreed that there's no one 'right way' to prototype and gather feedback.

A sketch is worth
a thousand words

Enabling the client to easily contribute effectively at the prototyping stage is really important. But not always easy when it comes to design.

Almost everyone can hold a pen and sketch on paper and this is a really effective way of grounding ideas in reality. When face-to-face collaboration is difficult or impossible, Google Hangouts can be used with webcams pointing at the paper while each party sketches their ideas. If you talk as you draw, the Hangout will switch to your camera – it works really well.

Another method suggested was to provide the client with some basic training in a simple wireframing tool like Balsamiq, and encourage them to express their ideas through it if they really don't want to sketch. Having used computer-produced wireframes in the past, I have found them to be too hi-fidelity and misinterpreted as design, so this is always worth bearing in mind. Collaborate, then interpret, test and refine collaboratively.

Capturing feedback on static prototypes

Whether you are sketching low-fidelity prototypes or working up static designs like jpgs, feedback needs to be captured on these. Acrobat has reasonable annotation tools for PDFs, and this was once considered perfectly acceptable. But you end up with loads of versions and it quickly gets quite horrible to manage.

A few of us in the BoF use InVision app for presenting and capturing feedback on hi-fidelity visual design work. I prefer to only use InVision for discussing mood boards or specific design elements, rather than full-page prototypes, because HTML prototypes are a far more effective way to do this. Feedback on hi-fidelity, static designs will largely be limited to how an interface looks, not how it behaves when interacted with.

Capturing feedback on interactive prototypes

Fully interactive prototypes can more accurately communicate interactions and behaviours including, but not limited to, those that happen when the design responds to the capabilities of different devices. For people who aren't HTML/CSS gurus, Axure is a good choice.

If you have some basic knowledge in HTML/CSS, or are prepared to learn, HTML prototypes are in my opinion the most effective way of communicating the reality of an interface, and can be produced quickly using frameworks like Bootstrap or Foundation. These tools make it very easy to experiment with ideas; responsive, multi-device (mobile, tablet, desktop etc) layout changes, different UIs etc.

I use Bootstrap for my HTML prototypes. It's quick and the rest of the team is familiar with the markup it produces, so can pick up and make edits easily. Standardising around frameworks is always important in larger teams. To help describe my decisions, I use Bootstrap's 'popovers' for annotations. But capturing feedback directly on HTML pages remains a tough problem to solve.

Recently, I hunted around for a tool that allows any user to add comments directly to my prototypes in the browser, and found Protonotes. Protonotes is a really useful start and has certainly improved the feedback process, but because all the notes added are relative to the left and top of the browser window, the notes are only really good on fixed-width layouts. Even then they depend on the size of the browser window remaining roughly the same.

I am yet to find a perfect way of capturing feedback on responsive HTML prototypes. Maybe someone could create a firebug-like element picker, and when clicking on an element, a Bootstrap popover is created in the DOM via the nested selector. Just thinking aloud now. I'm looking forward to someone solving this problem!

Live collaboration on HTML prototypes

The last thing we discussed was collaborating live on HTML prototypes. This involves making live edits to your HTML and CSS so that you can refine the prototype together. I don't do this often in a collaborative environment, but when there is debate about things like the visual weight of one element versus another, or the language of a label or heading, it's far more effective to see the options than to debate about opinions.

I use browser-based code inspection tools like Firebug and Chrome inspector for this, but you could also have your coding program open and just refresh your browser. Teams and clients alike love the process – it's extremely effective when there are strong opinions and no clear 'right' answers.

If you get browser CSS synching set up, you can even make edits in the inspector and synch them to your CSS file, avoiding having to redo all the work later. Of course, this isn't for everyone. You have to be pretty confident with your coding skills to be happy doing this. And sometimes changes end up being too big to handle on the fly, so need to be picked up later and sent for review.

I really enjoyed the BoF – it was great to hear from other people about their processes and hopefully everyone else found it as interesting as I did!