At UX Australia 2013, Dan Saffer opened the conference with a talk about microinteractions.
Essentially a microinteraction is something you’d find on littlebigdetails.com — an interaction that’s small, often overlooked, or even subconscious. Something that helps to enhance the core experience, reduce frustrations, and offer an opportunity for a bit of humanization or even humor in a product.
There are many examples of awesome microinteractions. To give you an idea, some of my favorite are:
- Mailchimp – As you stretch the browser window the arm of the chimp stretches till it “pops” off!
- Chrome – When the search term is obscured by the search bar, it’s moved to the left.
- Hipchat (an Atlassian product!) renders hex color swatches in line.
- YouTube – The favicon changes based on whether the video is buffering, playing, or paused.
The concept of microinteractions is similar to an initiative I started at Atlassian when I joined a few months ago. Inspired by Ubuntu’s One Hundred Paper Cuts initiative, I launched a similar project in Jira Agile (formerly GreenHopper).
The Atlassian paper cuts project exists to work on small annoyances and low-hanging fruit; it aims to bring attention to microinteractions in our products.
Paper cuts are triaged and labeled by myself and members of our team. The rules around the paper cuts project are simple:
- They should provide value to our customers.
- They should be simple to fix (in our case, less than one story point).
- We should strive to fix paper cuts in every sprint.
It can be difficult to focus on details when there are many other pressing issues; after all, as designers and product owners, we spend our days in an environment with a lot of history, old code, many feature requests, and many, many problems.
The paper cuts project helps to surface small issues which might otherwise be missed or “not considered important enough” to be placed in a sprint and worked on.
As you might have gathered, the name comes from the saying “death by a thousand cuts.” It is possible (and occurs frequently) to lose users due to sheer frustration and pain from small, repetitive, bugs and problems in our UI. In fact, a lot of our direct customer feedback mentions these issues.
So why not just fix them? They are easy enough to address, and we supply a lot of satisfaction for our customers by doing so. This translates into a morale boost for the team, as we feel we’re accomplishing something meaningful. In just two months, we have fixed 36 paper cuts in Jira Agile. Added up, these issues had over 100 customer votes on our public backlog, and some of them have been around for years.
The result is a product that is better and more polished, and customers who are happier because their feedback is being listened to. There are real user-facing improvements released every fortnight, and the team is energized and empowered by shipping things that are low effort to code, but have high impact.
Don’t forget the details, humanize your design and language, and look for opportunities in a user’s daily interaction with your software to introduce a microinteraction or fix an annoyance.
Oh, and read Dan Saffer’s book.