The internet of things promises a simpler, more intuitive world. Instead of asking people to do special things for the sake of technology, like pushing buttons, navigating screens or following a specific sequence of steps, products can now be designed around natural human experiences. Google Home and Amazon Echo do away with the interface entirely: Just speak into the air, and your wish is granted. (Steve Wilson, Citrix VP of product for Citrix Cloud and IoT, has a great blog on this: “4th gen user interface“). It’s a radical transformation, and one with thrilling potential — but the first step is to change the way engineers think about product design.
I don’t mean to bad-mouth engineers — I am one myself. But it’s our nature to approach things from an engineering perspective: How do I make these technologies fit together to accomplish a purpose? How do I get them to perform at a consistently high level? How much functionality can I deliver? These are all good intentions, and they make plenty of sense in many applications. But when it comes to IoT, it’s the consumer’s perspective that matters most — their context, their perspective.
Think about electricity. Consumers don’t care about the technical challenges that had to be solved to make it flow through their walls, and they couldn’t tell an amp from an ohm if their life depended on it. All that matters to them is that when they flip a switch (or trigger a motion sensor), the lights come on. That’s the kind of natural simplicity and invisibility IoT needs to achieve.
As an engineer, I also understand our inclination to figure things out ourselves. Solving problems is what we do. But in this case, it’s important for us to understand and accept the value of reaching out for real design expertise and following a structured design process. Instead of just engineering a product to work 150% better, you’ll end up creating an experience that delivers 10 times better for the consumer.
Here are a few of the principles I’ve learned by collaborating with the designers at Citrix.
Know what problem you’re solving
You’d be surprised how often people design products without a clear idea of the problem they’re solving. They’ve got a technical innovation that they’re eager to productize, or they’re on a mission to squeeze even more functionality into an existing product. One good reality check is to see if the product manager can tell a simple narrative about the proposed product in a consumer’s daily life. If it seems contrived or farfetched, you’ve got a problem.
To begin with, pay attention to people’s behaviors today so you can document the friction they encounter. What frustrates them? What gets in the way of more interesting or important things? What would they like to be able to do more easily? Meeting technology is a classic case; we’ve all suffered the agony of watching someone fumble with computers, projectors and videoconferencing gear while valuable minutes tick away. But remember, the goal isn’t to make it easier to connect a computer — the goal is to make it easier for people to share information and collaborate. Don’t mistake the tool for its purpose.
Empathize with the consumer
As you’re researching the right problems to solve, remember that the beauty of your technology will be in the eye of the consumer. It’s their priorities and needs that matter, not yours. How many applications end up with barely usable interfaces because they’ve been assembled from an engineering perspective instead of a user’s point of view?
Take the Nest thermostat, for example. Did I buy one because of its technical horsepower or engineering brilliance, or because of purely rational considerations of energy conservation and money savings? I’d like to say yes, but in reality, I just couldn’t resist the way its elegant design called out to me and made me want to interact with it. Like so many Apple products, the Nest thermostat put design front and center while getting technology out of the consumer’s way. And as with Apple, it didn’t even matter how much more expensive the Nest was than the alternatives. Now, this beautiful widget has led the way for a whole host of home automation products from cameras to smoke detectors under the Google umbrella.
Citrix applied this kind of approach in designing the interface for our Octoblu IoT platform. IoT automation can get complicated quickly, from the devices you need to connect to the protocols that make it work, but the goal of Octoblu users is to create experiences, not write code. We made a point of providing a drag-and-drop interface that lets people build complex automations simply by specifying a sequence of actions — when your car pulls into the driveway, your garage door opens, the lights come on and your house unlocks. Remember, elegance wins.
Use a design brief
So, you’ve identified the problem you’re going to solve, and you’ve put yourself in the mindset of the consumer. How are you going to deliver the product? A formal design brief can ensure focus and discipline so you can avoid getting carried away with extraneous features or mission creep. It’s also a good vehicle for collaboration between engineers and designers — it’s an opportunity to check each other’s thinking, so that designers work within the realm of engineering reality, and engineers maintain a design-thinking orientation.
The brief should encompass:
- A problem statement. What are you solving? What’s the narrative from the consumer’s perspective?
- The business rationale. From both a design and an engineering perspective, why is this the right problem to be solving?
- The “before” picture. How are people doing it today? Where does the friction reside?
- The “after.” What is the kind of experience you’re seeking to design? See if you can tell a few stories about people interacting with the experience. How are you meeting their needs?
My colleague Todd Rosenthal, Citrix director of product design for IoT, analytics, mobility and app management, likes to think of this in terms of creating a better relationship between technology and people. Your goal is to support the user’s ability to smoothly move between activities (such as driving, walking and sitting), places (a room, a car, a campus) and things (devices, apps, sensors). Your goal is to ensure that the user’s needs are met in the context of these three variables — Todd represents them as points of a triangle in the diagram below. You’ll note that the user is always at the center of the experience.
You can find more of Todd’s design insights here.
It doesn’t necessarily take a designer to create a design brief. The important thing is to get the product manager and engineer together to agree on the design principles that will guide the project, with a common language, equal ownership and the flexibility to evolve as needed to get the product right. At Citrix, we’ve used a Slack channel to complement weekly meetings with real-time communication between engineers, product managers and designers, and I’ve been struck that the more we work together, the more our thinking comes into sync, so we end up having similar ideas at the same time.
If you think you don’t have time for a design brief — that you’ll just tweak the design as you go — remember that the world is full of $30 thermostats that may have even more features than Nest, but don’t have a fraction of its appeal or sense of purpose. Engineers want to see how many feature bullets they can put on the box, but people are digitally distracted enough as it is — they want simplicity. With this process, you’ll find the one or two features people will benefit most from right away; you can always add more in future releases. Remember, the original iPhone didn’t even come with the App Store ecosystem — it was laughably under-featured in today’s terms. But it became one of the most important and successful consumer products in history.
Products that don’t consult design aren’t maximizing their full potential and opportunity. By bringing design into the process from the very beginning, you have a chance to deliver a product that’s 10 times better from the consumer’s perspective — while bringing in 10 times as much revenue per unit for your business.
Your goal isn’t to impress the consumer. It’s to help them. Sometimes, that means leaving some things in their own hands and resisting the temptation to over-automate. When people walk into a conference room, they don’t necessarily want all of its systems to fire up right way — that might feel pushy or annoying. They’d prefer to spend a few minutes shaking hands and making small talk before Skype starts capturing every word they say. Don’t assume that more automation is always better, and don’t engineer in a silo. Social norms may not be an engineering principle, but they should be a key part of your design context.
Of course, IoT design can have a way of humbling any engineer. Adding features is easy; simplicity is hard. It takes discipline to deliver experiences designed around human needs and quirks rather than technical wizardry. But when you get it right, you can change the world.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.