Lately, the idea of designing for less interaction within an app has been popping up all over our projects. To clarify, by out-of-app experiences, we’re talking anything from phone notifications to third-party service integrations. It can also include the connected device itself, or it could join forces with other services.
When designing for connected products, it’s dangerous to fall into the trap of jam-packing the app with data and features, forgetting that the app should take on a supporting role to the product that the user invested good money in. Naturally, product stakeholders are eager to give users everything they could possibly want out of an app. While this is a commendable desire, it often buries the core functionalities beneath comparably impractical features. Shouldn’t the user be able to first achieve the product’s main function?
##A different point of view Working with clients like these has become the norm for me; a single project would have dozens of stakeholders, each with their own agenda, all wanting their own priority to be the app’s priority. It was a refreshing change to work with a smaller client with an opposing goal. Rather than loading the app with features to prove its worth, this client wanted us to design an experience that required as little entry into the app as possible. The less the user had to open the app, the better. What this meant was that we had the opportunity to push the product’s primary functions outside the app, letting widgets, notifications, and force touch options handle the core functionality.
What was left was an app that could be designed so that compelling data and relevant visualizations could be integrated in the future with less risk of clutter. Core functionalities were still prominently shown, but because the user doesn’t need to launch the app to access it, we can offer more information with less worry about the app’s complexity. Power users who love data and want to make the most out of the connected bike can opt for that experience, while the user who simply wants the bike to work won’t be forced into it.
##A push further Immediately after wrapping that project up, we started another and integrated the lessons learned into the five directions we presented. In fact, we decided to be so bold as to suggest that the fifth direction didn’t even include a central app. Rather than relying on an app to house the many features, we allocated jobs to multiple touchpoints. For example, setting up the device could be done via home assistants such as Echo or Google Home, while help could be provided through Facebook Messenger bots.
What I found most interesting about this direction was that the service came to the user. As a consumer of connected products, the user is expected to get what he needs by accessing the app. But perhaps the next step is that the app is the one that comes to the user at the most relevant times and touchpoints. If we’re selling “smart” products, it seems natural that gentle guidance can be integrated into the user’s day without relying on the user to be proactive about it.
Moreover, by spreading efforts across multiple touchpoints, it’s easier to adapt to new technologies. What’s currently best solved by phone screens could soon be better handled by smart mirrors or a smart car’s dashboard.
##Designing for multiple touchpoints Brands typically rely heavily on the visual aesthetic establish their identity. When moving towards a direction where little or no control is given to third-party integrations, how can the experience remain branded? How can we establish trust and credibility when the user may likely attribute the seamless experience or helpful advice to the touchpoint we reach them through?
To pull one one of Steve Jobs’ most quotable quotes, “Design is not just what it looks like and feels like. Design is how it works.”
When thinking about things like voice-controlled home assistants and chatbots, what it looks and feels like (if even applicable) is usually determined by the service itself. Here, tone-of-voice becomes your most valuable tool; this is how it works.
When Siri, Google, or Alexa starts giving drill-sergeant demands, it’s a very different experience than giving sassy recommendations. Designing the experience then becomes like designing a character. How would this character provide encouragement, and how does it handle stressful moments? Perhaps this tone-of-voice is so concrete that it becomes a mascot, complete with a name and values. Or perhaps the mascot has a subtle presence, and isn’t recognized by name or appearance but is always perceptible in experiences.
As an experience designer, I look forward to working through the many hurdles I’m sure this transition will surface. Get ready to start creating decision trees and scripts over redlines and design guidelines.