Why showing 'the thing' is important

Why showing 'the thing' is important

I spent some time this year looking at framer.js and working out how it would fit into my workflows. Sadly it doesn't. Well, not currently. It doesn't currently because I'm quicker with other tools, and I'm a big believer in speed of execution - whatever it takes to 'show the thing' for initial feedback is the right tool to use. I use a lot of paper prototypes, but my normal workflow is:

Paper sketch > Paper prototype > InDesign wireframes (basic) > Feedback > InDesign wireframes (mid-def) > Engineered prototype (pair coded) > User testing

However, I've also started to add some tools to my toolkit for certain scenarios (usually visually lead stakeholders, AdTech people and content publishers). I'm a fan of Flinto for mobile mockups to demo transitions for example. I've used InVision before to mock up basic interactions for pitches and quick user testing (see here). For specific interactions I've even used After Effects - mainly because I'm pretty proficient in it after my time in broadcast design, but also as it sometimes has the nuances of actual interactions. By that I mean Z space, speed and time. The danger of After Effects prototyping is obvious - it takes ages to build and render and it's not 'hands on'. But sometimes it's a great tool to show the scope of interactions and it can be a great tool to bring designs to engineering when pair programming isn't an option (for example in multiple timezones). It's also a good way of breaking down animations and interactions into frame-by-frame elements. To give you an example, below are two videos. One is a high definition finished product I was working on at Dennis Publishing, which has been screen recorded with actual user interactions. Below it is an After Effects render of a mid-def wireframe to show proposed user interactions, prior to it hitting engineering. Sometimes interactions can make flat prototypes - well - make more sense.

Whatever it takes to 'show the thing'.

When to design - and when to *design*

When to design - and when to *design*

How to build something Delightful

How to build something Delightful