Prototypes play an important role in the design process. They help communicate ideas to stakeholders, specify interactions for developers and test early product versions with users. When you’re interacting remotely — either as a team or with clients — your prototyping tools should make collaboration easy.
What I learned from The Evolving Role of Expectations in Long-Term User Experience by Sari Kujala and Talya Miron-Shatz (published in September 2015):
Between Christmas and New Year I found the time to read through two great books. Both are short, entertaining and insightful. One introduces the practice of Information Architecture, the other illustrates basic principles of visual design. I recommend them to anyone who wants to learn more about the essentials of user experience design.
Last Saturday I had the pleasure to do a session on remote work with distributed teams at UX Camp Hamburg — a perfectly organised and fun event.
UPDATE: Instead of continuing with part 2, I decided to not label articles “part 1” again and instead talk about the topic, collect more ways to do ux work remotely on Twitter and write more specific articles on the subject.
Lately, I’ve been working more and more with teams spread across different cities, countries and timezones. Though there are times when it’s difficult not having everyone in the same room (you know the drill), user experience design can work quite well remotely when you give thought to the tools and methods you are using. Starting with ideation and sketching, I will have a closer look at how the different steps of the ux design process are affected by remote work.
During the past few months, I’ve had a longer commute than usual. This is why I subscribed to a lot of new podcasts. Compared to my experiences from a couple of years ago, podcasting has really evolved. There are a lot of quality podcasts out there – both from traditional publishers and independent podcasters. The following podcasts are my favorites right now.
Today’s awful weather was perfect for rereading 101 Things I Learned In Architecture School. It’s a short book I bought a few years ago for a UX Book Club meeting. Matthew Frederick included a few thoughts particularly interesting for user experience designers:
Some interesting thoughts from 7:16 to 9:02 on how governments communicate with their citizens and how designers could fix it.
There is still horrible government communications. If I look at the text forms. They are just as bad as they were forty years ago. And I could make them a hundred times better in two days. But they don’t realize it’s something that people can do. They go to their advertising agencies, and their advertising agencies aren’t interesting in forms. You know, they do big campaigns. And if they came to me, I would do the form, not the campaign. […]
Two weeks ago, I spoke at World Usability Day in Hannover. Among great talks on flat design, feedback forms and gestural interaction, I had the pleasure to talk about prototyping in cross-device design projects. Unfortunately, I could not go into details of the tools I presented (in German). I would like to take this as a starting point for a series of blog posts.
How can we talk about physics-based UIs and panels and bubbles that can be flung across the screen if we’re sitting around looking at static mocks? (Hint: we can’t.) It’s no secret that many of us on the Facebook Design team are avid users of QuartzComposer, a visual prototyping tool that lets you create hi-fidelity demos that look and feel like exactly what you want the end product to be. We’ve given a few talks on QC in the past, and its presence at Facebook (introduced by Mike Matas a few years back) has changed the way we design. Not only does QC make working with engineers much easier, it’s also incredibly effective at telling the story of a design. When you see a live, polished, interactable demo, you can instantly understand how something is meant to work and feel, in a way that words or long descriptions or wireframes will never be able to achieve. And that leads to better feedback, and better iterations, and ultimately a better end product. When you are working on something for which the interactions matter so greatly—in this case, a gesture-rich, heavily physics-based ui—anything less simply will not do.