When trying to communicate a design idea in a work environment, it is essential that you do so in the most effective way possible for all parties involved. You want to be as clear and as purposeful as possible, and make sure the delivered message lends itself to meaningful feedback and action. How you communicate the idea is, in some cases, as important as the idea itself.
This is especially significant in a remote work setting. At Automattic, the majority of the communication is in written form in private blogs, and posts multiply at an exponential rate, so every second spent understanding and interpreting someone’s point of view is valuable. Working remotely also means you can’t just knock on someone’s door and discuss a concept with them. You could spin up a follow-up call however, as we sometimes do, but that’s usually a 1-to–1 ratio, and you want to be as 1-to-many as possible.
There’s a story to be told
We, designers, are curious creatures at heart and like to try all sort of cool tools: from the most barebones wireframing app, to quick prototyping an interaction with code using a framework. This sort of meta work and experimentation allows us not only to stay fresh and “sharpen our axes”, but to adjust our approach depending on the needs of a singular project too.
Above all though, designers are storytellers. And as such, our job is to provide a narrative and structure that make sense, articulate a point of view, in its detail and nuances. This is certainly valid for the end user, but equally valid for the team involved in the task to bring that design to life — in a way, they’ll be the first to validate it.
For example, while it might be totally fine to use a doodle on a napkin to convey an idea to another designer, the chances of that working in a large and diverse group of people aren’t great. Besides having no inherent context, there’s a wide spectrum of people to consider and we all come from different backgrounds (UI designers, marketing designers, developers, business people, etc.) so there’s room for a lot of (mis)interpretation.
Translating a low fidelity sketch to higher fidelity mocks.
The medium matters because it is the vehicle that carries your message, your intent. We owe it to ourselves, our peers, and our users to be thoughtful and complete, clear and thorough. From its inception to its fruition and iteration, that storytelling aspect has be a constant throughout a product’s lifecycle.
Going Mo-Hi-Fi
So how can we make sure we’re telling the whole story and embracing as many people (and backgrounds) as possible? In our world, that story is a flow of user interactions that jump to different links in the chain, trigger UI reactions, that make it change, evolve, and adapt — in other words, it’s a progression (think movie): it has a beginning, a middle, and an end.
As mentioned in the example above, low fidelity sketches or wireframes have their purpose, but they’re impractical because of the lack of concreteness. Generally speaking, a higher fidelity prototype is more likely to create an immediate emotional connection, it’s more relatable, and helps avoiding ambiguity.
Screenshots are generally a bad representation of a flow, exactly because things change, and now that animations and transitions are an established part of the enhanced experience, it’s vital that our medium of choice can represent them. Those are subtleties that tighten up the user’s experience, but are left out if you’re only showing discrete UI views.
Enter Mo-Hi-Fi, or Motion High Fidelity.
If we go back to the movie metaphor alluded to earlier, think about the difference storyboards vs moving pictures. Storyboards are a great visual starting point, but what happens between two of them? Likewise, by not addressing the interstitial steps that happen between two UI screenshots, much of your intent is left to be extrapolated.
Lately I’ve been working on a couple of new features on WordPress.com — namely an activity stream that offers site restores and the ability to clone a site —, and I found myself needing a richer way of presenting ideas. The solution I’ve been using and iterating on a bit is to show a continuous flow using a screen recording of an interactive prototype.
Using more complex animations to illustrate the logic behind the UI.
- I first create high fidelity mockups in Sketch using dynamic symbols that help speed up the process. We’ve refined these over time so that anyone with an idea can jump in and build a high fidelity interface in the same amount of time that a sketching up a wireframe would take.
- Then I import these over to Flinto so that we can build interactive prototypes. I’ve also tried Principle in the past, but Flinto provides an amazingly granular control over transitions and animations, not to mention the almost flawless 1:1 mapping of Sketch artboards, groupings, and layers.
- Finally I record the screen of myself using the moving thing, which is a built-in feature in Flinto. This often doubles as a first user test — you’d be surprised the amount of things I catch on this phase that somehow didn’t see before.
- Sometimes I’ll even add some voice-over if the prototype is too complex or I want to add extra context. Talking about the UI also helps walk through it with a fresh perspective.
Even without using custom animations, it can be helpful to visualize flows as a singular, uninterrupted stream.
By showing off a continuous flow you end up with a much deeper understanding of the entire scenario, the steps in-between, creative ways of how your UI behaves, etc. All of that leads to a much more compelling and complete storytelling aspect of your perspective.
Seeing is believing, and if a picture is worth a thousand words, then a moving prototype is worth five thousand more.
Automattic Design 