Every now and again, an excited client we’ve just landed will expects to see something a couple of days after the workshop. Getting through the concept of research and discovery across during the initial conversations is one thing, but given how enthused our clients can be, we often found ourselves working on improvements to what we hand over for sign-off. Be it wireframes releases or concept designs – how do we bring it closer to how the finished product will work, look and feel like? Prototyping our work was the obvious choice from the start, but it led to more questions:
- Do we prototype every stage?
- What’s important for each stage of the project?
- What are the priorities for the stakeholders?
- What will get us a sign-off from the client and allow to move forward?
- How much time will it take?
TL; DR: There is no silver bullet. We haven’t yet found an app to present designs as they’d appear when built and that would help us do that. (Plus woo the client enough for instant sign-off, provide prototypes without getting into explanations why this looks half-finished and why that can’t really be clicked, AND makes us all gloriously thick espressos first thing.) Regardless, we’ve come a long way since uploading a JPEG of an interface and a note to Basecamp, counting on the client to get what we’re about.
Here’s what grabbed our attention along that way.
Wireframing with Weld
Following the initial research and user interviews, the first tangible deliverable we present to clients are wireframes. Their black and white, spartan appearance can be confusing, to say the least. Often, we chatted about moving wireframes into the browser and how that would help our clients understand what’s going on early on in the design process.
We struck gold with Weld. Not only did we get clickable prototypes right there in the browser – with a couple of clicks more we could make them responsive! Starting our designs in the browser (and working from the Mobile view up) got us thinking harder about hierarchy, flow and clarity of calls to action. We opted for a descriptive approach and minimum visual procrastination. No more picking typefaces for headings or border-radii for buttons while designing an initial wireframe!
Weld prototypes are responsive! Image source: www.weld.io/
Sure, the wireframes remained monochrome. But seeing them in the environment the finished product would inhabit, clients got to grips with content flowing between Desktop and Mobile, clicked buttons, moved freely from page to page and inputted text into form fields. We noticed a shift in focus – from the initial anxiety wireframes brought – “I’m not sure about this… Is it not too dark for a website?” – to “Yeah, I understand what this is” and nods of agreement.
Working out interactions with Framer
With a couple of days spare on the design team’s timesheet, prototyping microinteractions or module behaviour goes a long way. Succinct, informative briefings are difficult enough when describing interactions or screen behaviour. Zoning in on a specific module with a couple of before & after JPEGs is far too general a way to design and build a flow. Throw an in-between state or a specific transition and… welcome to ambiguity land.
Here’s where Framer comes in. Importing your PSDs or Sketch files, giving you full control over events and giving us surgical precision when tweaking those timings and curves down to decimal points.
Framer came with one caveat. You had to be comfortable enough with JavaScript (emm… CoffeeScript, its curly-braces-hating kid cousin) to unleash its potential. Without asking if designers should code ( ¯\_(ツ)_/¯ ), for the purpose of this post let’s just assume we all have a working knowledge of CoffeeScript.
I don’t recall ever using Framer to work out the behaviour of a page design or create a detailed walk-through for a flow. Partly because having to plan out all the moving parts and jump between a static, visual mindset into a build and then back again carries a quite a lot of mental effort. Yet, when it came to single interactions, or chaining a couple of transitions together to show our developers, we found no better tool.
Framer has a lot more to offer than chaining simple interactions. For an intro tutorial, check out Framer.js for people who think things like Framer.js are weird and hard, where this GIF came from.
Importing elements from a PSD means the layout is preserved in the Framer workspace, and working with code allows us to chain transitions, execute in a cause-and-effect manner and control the PSD layers in a similar way to how our developers would HTML, using CSS and JavaScript. Framer’s primary function is being the quick response, precise fix tool I carry in my belt.
Getting the concept across with Principle
What about concept designs and bringing them to life, though? Less “prototyping” and more “delighting”, for when the project (and client) demands it? It used to be the job of a bunch of JPEGs and a concept note document, and they were working hard to get us through that stage of the process – until we discovered Principle.
Once Principle sprung onto the prototyping scene, it fit into our workflow quickly and seamlessly. Using artboards mimicked the way we put together screens in Photoshop or Sketch. Controlling transitions through a GUI instead of code felt like we could leave precise tweaks ’til last, and push forward guided by our eye and gut feeling. Even the default transition curves are a thing of beauty! If speed is what you’re going for, uploading assets and linking them into a simple flow is a breeze. Adjusting the timing and validating the idea we just had takes a couple more minutes. Rinse and repeat, if necessary – Principle’s UI won’t make you fiddle with a hundred settings just to get a simple transition right.
Principle UI looks familiar, doesn't it? Source: principleformac.com
“… here’s what we believe should happen on page load / click / drag” — a .MOV export turned out to be a helpful client deliverable. Even without making it clickable, a little life inside a concept design meant bringing it one step closer to the finished product. If an image is worth a thousand words, a MOV clip is a client sign-off note, worth hours of edits.
Bringing it all into a system with inVision
Hi Clark! Thanks for all your emails ☺
Are there still designers out there who aren’t familiar with InVision? It’s the very first tool we have adopted for prototyping, and it comes in quite handy at different stages of the process. It doesn’t boast baked-in responsiveness and won’t help speccing out interaction-heavy modules, but it offers a bird’s eye view of the project at hand by uploading screens and linking them up.
We’ve used inVision for wireframe and high-fidelity site models, internal and client feedback, testing, even copy input through comments and it worked for us every time (unless we got distracted while manually linking the screens, of course).
Where to next?
We reshape our process depending on the needs of the projects at hand – and, ultimately, it all boils down to stakeholders’ requests. Whatever tool or technique helps us minimise ambiguity and anxiety in client relations is definitely worth a try. Whatever smoothens out our internal back-and-forth is going to get a shot. Each of the tools we use regularly has to bring value and help us make correct decisions together. It has to help the end result come out as good as it can be. It should assist us in answering questions we might have difficulty tackling otherwise.
In the end, prototyping for us is just as much about verifying assumptions through research as it is about communicating our design decisions throughout the life cycle of a project to stakeholders whose expertise lies in a completely different field.
