How we built it: Listen to your customers, especially when they stop talking

1 Comment

To help aspiring entrepreneurs understand what it takes to translate an idea to an actual product, we recruited six hardware entrepreneurs how they did it. They’ll be presenting some lessons and answering your questions at our Structure Connect event Oct. 21 and 22. Below is the second in our series written by Peter Hoddie of Marvell on how to challenge your ideas in the face of customer action (and inaction).

When it comes to prototyping a device, it is banal for product designers to say they listen to the customer. We build prototypes for potential customers to respond to. We hope the prototype will validate our design choices, but sometimes it won’t. So listening to what users say and don’t say — observing what they do and don’t do — can lead to huge improvements. But you have to look past the good news for the bad.

When we set out to build Kinoma Create, itself a device to help makers build their own prototypes and validate their design choices, we learned this over many design iterations. And as an example of looking past the obvious feedback to see what was left unsaid, we can look at our decision to add a touch screen.

The touch screen became a defining feature of the product, despite being deliberately omitted from the first prototype.

Prior to starting Kinoma Create, my team constructed several prototypes of consumer electronics devices. They all had a screen, but not a touch screen. Through good design, the users of those devices didn’t usually miss the touch screen. The reason we chose not to include a touch screen was cost. In modest quantities, the price of a small LCD can jump by $10 when capacitive touch is added, which can translate to a $30 higher price tag at retail.

Yet we found similar patterns and problems recurring when constructing our initial consumer prototypes. So to solve that, we decided to build a hardware tool to help makers build their own prototypes. Our K4 prototype, which became Kinoma Create, began as a way to solve the problems and slowdowns we encountered in our own prototyping.

To provide flexible user input, K4 had touch sensitive strips on each edge of the screen. Through code, developers could transform the touch strips into buttons and sliders. This allowed for a variety input configurations without changing the hardware. And the cost was minimal – comfortably under $1. It was cool and different. The lack of touch challenged the developer to invent new interaction styles, and to confront the balance between production cost and product functionality – a great lesson in delivering commercial products.

An early Kinoma Create without a touch screen.

An early Kinoma Create without a touch screen.

We quietly demonstrated the first generation of K4 at South by Southwest Interactive in 2013. It was well received, but everyone wanted touch.

Everyone.

After explaining that touch would increase the price, our potential customers were undeterred. Developers have become accustomed to touch on mobile device screens, so they expected any device with a similar screen size to support touch.

We added touch.

It turned out to be pretty amazing. Most “Internet of things” devices do not have a screen, often for cost reasons. So developers creating those devices typically work on their computer, typing obscure commands to probe or configure the gadget. But when you add a touch screen they can display diagnostic information on the device, add controls to change the device state directly. It seems simple, but it fundamentally changes development.

Problem solved. Touch screens were great.

The current Create with launch software.

The current Create with launch software.

Then we went back to SXSW in 2014. Our colorful hardware, novel industrial design, and demo projects pulled makers into our booth. They picked up our device to explore its capabilities, but if the Kinoma Create wasn’t running an existing project, it had no built-in behavior, except to wait for the developer to come up with an idea. It was a blank slate. Our potential customers walked away.

You can’t listen to people walking away. You have to pay attention.

We understood that our potential customers expected the device to do something in and of itself. But what? Kinoma Create isn’t a phone or a tablet: a typical consumer mobile experience would be out of place. We considered providing demos and tutorials, but those don’t help developers day after day.

We went back to first principles. Kinoma Create is for developers. It should have a developer user experience. That’s easy to say, but discovering what it means has been a challenging journey. We imagined a device where each app is for developers. The starting point for many of those apps are the command line tools we use in our own development, rethought with a mobile touch user interface.

Normally, the fundamental design principle of mobile is to hide complexity, but developers need access to that information to do their work. As we have begun to share our developer user experience with customers, they have responded with surprise and delight. Many have wrestled with the same challenges we have. They appreciate that by adding a touch screen to a prototyping device – we are addressing those challenges.

Listening brought the touch screen to Kinoma Create. Watching told us we weren’t meeting user expectations for the touch screen. And that led us to fundamentally rethink how we could build our product.

Learn more about building the Kinoma Create at Structure Connect Oct. 21 and 22 in San Francisco, where Hoddie will spend more time discussing pricing tradeoffs and the benefits of prototyping in software.

How-We-Built-It-ticker

1 Comment

jjj

Not a developer so don’t count my suggestion as one from a client.
How about adding some power harvesting tech and a tool that monitors and provides stats. It would at least put it on their radar and maybe inspire to explore such solutions leading to better devices.
Maybe it makes as little sense as including a touch screen at first so it could be easy to dismiss. Power and weight can be major problems and actual devices that harvest any power seem just too rare.
For devs a product that harvests some or all power is a huge marketing asset , for users it should be more convenient.
Maybe it’s like including a touchscreen before touchscreens were the norm or at the very least makes the demos more appealing.

Comments are closed.