By Eric Weddington, Marketing Manager, Open Source & Community
Sally Carson, co-founder of Pinoccio
Sally Carson, co-founder of Pinoccio
In February I did an interview with Eric Jennings, co-founder of Pinoccio. Pinoccio is a new Open Source Hardware business, building “a complete ecosystem for the Internet of Things”. The Pinoccio is a pocket-sized microcontroller board, with wireless networking, rechargeable LiPo battery, sensors, and the ability to expand its capabilities through shields, much like an Arduino board. It features the new Atmel ATmega256RFR2, a single-chip AVR 8-bit processor with low power 2.4GHz transceiver for IEEE 802.15.4 communications.
Pinoccio featuring new Atmel ATmega256RFR2
Eric Jennings, along with his partner Sally Carson, co-founded Pinoccio. In my interview with Eric Jennings he said:
Eric Jennings: Sally Carson, Pinoccio’s other co-founder, is an expert in the intersection between humans and technology. What I mean by that is that she thinks very deeply and carefully about the psychology of humans interacting with computers. Human-computer interaction, user experience, and usability all fall under her umbrella. I consider her contribution a secret weapon in what we’re trying to achieve with Pinoccio.
A Secret Weapon?!… I had to find out more what Eric meant, and just what exactly is Pinoccio’s Secret Weapon. I contacted Sally Carson and asked her about the intersection of User Experience (UX) with electronics and the design of the Pinoccio. Along the way, I learned some good lessons on why Design is important, even to just a set of electronics.
Eric Weddington (EW): What intrigued you about the Pinoccio to co-found a hardware startup company?
Sally Carson (SC): Well, I was always a creative kid, always drawing or making something. And, I always loved fiddling around with gadgets and electronics. In high school, I became an audio/video nerd. I got into skateboarding and playing in bands with friends. But, a huge part of both of these hobbies was the A/V part. So, for example, I filmed tons of footage of my friends and I skating. I would make these skate videos, editing the footage down using two VCRs. I’d use a 4-track to mix in audio, or I’d splice in the audio from an old Nintendo, like from Teenage Mutant Ninja Turtles. Every time we ollied or did a trick, there would be the “bloop” sound of a turtle jumping. So, I wasn’t like, busting out the soldering iron, but I was trying to find all of the different ways I could combine the electronics that I had access to.
Later on, I became a Web Designer and suddenly all of my creative output was virtual and done on a computer. I missed the physicality of using my hands to make things. Tim O’Reilly was a big influence on me, and I tried to keep up with whatever O’Reilly Media was putting out. I cut my teeth on the Web Design In a Nutshell book. I listened to podcasts of ETech and the Web 2.0 Conference.
Around 2004, I started to specialize in Interaction Design, and I was really interested in the Interaction Design Institute of Ivrea — where Massimo Banzi was teaching, and where Arduino was being developed. They were teaching Interaction Designers to prototype and test their product ideas by quickly building a physical prototype. This was fascinating to me — you could still be a Tech nerd but also build things with your hands. That blending of physical and virtual was super compelling; I always thought I had to choose one or the other.
Then, I got the first issue of Make when it came out, and I was totally enchanted. Make had found this incredible group of people who were tech geeks like me, but who knew how to build real things with their hands. I filled sketchbooks with ideas for DIY projects that I personally wanted to build. But, I still felt this barrier to entry and I hadn’t yet found a community of Makers who could help me. Every project I wanted to build needed to be wireless and Web-enabled, but that seemed totally out of reach for someone like me who wasn’t deeply technical.
I think there are a lot of people out there like me, who are somewhat geeky, but not super “deep geeks.” They want to build wireless, web-enabled projects but they don’t know how and they’re not sure it’s even possible. With Pinoccio, we’re providing all of that scaffolding for you. Your board is talking to the Web wirelessly within minutes of taking it out of the box. It already has a rechargeable battery that can last for weeks or months. From there, it’s up to you to start imagining possibilities for this platform. We want you to focus on the specifics of your project, instead of losing momentum trying to figure out all that other stuff.
So, with Pinoccio, I got really excited about enabling other people to build cool projects like the ones I had been dreaming about for years. There’s something really magical about creating a tool that enables other creative, talented folks — there’s this amazing multiplier effect.
EW: The Pinoccio could be looked at just the electronic guts of a larger system, as just a set of functions to be implemented. You and Eric Jennings see a need to approach the problem differently with Pinoccio. What led you to do this differently?
SC: The two most basic questions that I ask when I’m designing a product are: “Is it useful?” and “Is it desirable?” I want the answer to both questions to be yes.
If we had approached Pinoccio as “just a set of functions to be implemented,” we would have been building something useful, but not desirable. And that’s when you run the risk of commoditization. Your customers won’t have any particular loyalty to you, they’ll simply comparison shop between functionally similar products and choose whatever’s cheapest. Even if you’re first to market, this makes you vulnerable to cheaper knock-offs in the future.
So we want to be both useful *and* desirable. What does that look like? Let’s take Sugru as an example. Sugru is this magic, self-curing rubber that you can use to fix or modify practically anything — tools, electronics, everyday objects around the house. I had a sample packet laying around for a few months. I understood what it was, I understood the usefulness of it, but it wasn’t yet desirable in my mind.
Once Fall rolled around, I was commuting by bike at night, and I was frustrated with my new headlight. It had this recessed on/off button that was nearly impossible to press with thick gloves on. I used Sugru to fatten up the button and make it taller. The next day, once the Sugru had cured, I tried turning my light on and off with gloves and it was way, way better. I FELT SO SMART AND AWESOME! That was the moment that I fell in love with Sugru, because of how it made me feel about myself. I felt clever, capable, and industrious.
Now Sugru is both useful and desirable to me. I want to use it again, because I want to feel smart and awesome again. I want to show off what I “made” to my friends. It’s less about the Sugru, it’s more about how it made me feel. That “a-ha!” moment is what we’re shooting for with Pinoccio. We want to build a useful tool that makes people feel smart and awesome. We want to reduce those frustrating barriers to entry so you maintain your motivation to see a project through to completion. Then we want you to share what you built, show it off online, and collaborate with others who are working on similar projects.
EW: How is the process of designing the User Experience for the Pinoccio different than for other products?
SC: When I’m designing for the Web, I try to put together a functional prototype as quickly as possible, even if it’s just a clickable simulation comprised of sketches. Then I test it with real users. But, this is harder to do with hardware, it takes a lot longer to get to the functional prototype phase.
So, we used conferences like the Open Source Hardware Summit as an opportunity to interview potential customers and ask them about what they have actually done in the past. Have they tried to build a web-enabled project? How were they powering their projects? What tools did they use? What was frustrating? What worked well? This is a lot different than asking them if they think they would use Pinoccio, or asking them what features they’d like to see. We tried to identify existing pain points, based on the actual previous experiences of our target audience, then shape features around those insights.
EW: What part of the design process of the Pinoccio surprised you?
SC: I wouldn’t say I was surprised by this exactly, but I am constantly amazed by how awesome our community is. They’re brilliant, creative, and determined. They’re also incredibly generous and it’s super fun to see them sharing ideas and helping each other. I guess it surprised me how much idea exchange is already happening between members of the Community. It’s really rewarding to see that happening, and being an open source hardware company made it possible.
EW: What was the biggest challenge of the design process of the Pinoccio, and how did you overcome it?
SC: Well, for Web-based products, we try to build a Minimal Viable Product, get something into the hands of users as quickly as possible, see how they respond, then iterate and evolve the product organically from there. That’s a lot easier to do with software, because it’s relatively fast and cheap to put together an MVP.
Hardware is slower, it’s more expensive, and it’s inherently a “Waterfall” process — meaning there are a series of linear dependencies and the project can’t advance until each phase is complete. For each iteration, you have to make design changes to the board, order components, order PCBs, get the boards assembled, test them, rinse and repeat. It’s a weeks-to-months iteration cycle, instead of the hours-to-days cycles that we enjoy in Web Development.
I think the way that we address this is to bring assembly in-house. That will really allow us to take advantage of these Agile methodologies that we’re used to — rapid iterations of testing and refining. It will let us tighten up those cycles of iteration.
EW: What are some common mistakes that you see in hardware product design, that don’t take into account User Experience?
SC: Well, I think for any tech product, be it hardware or software, it’s tempting to think about features first, and to create a list of technical requirements as a starting point.
What we try to do instead is to think deeply about who our customer is. We think about what Peter Merholz calls their “emotional requirements.” What are their needs, motivations, and goals? What excites them? What frustrates them? How does Pinoccio fit into their lives, and how does it fit into a typical day? We answer these questions via different methods of qualitative research, including ethnography and interviews. It’s not enough to ask your target audience if they think they would like a particular product or feature. People are famously bad about self-reporting, it’s better to observe what they actually do, as opposed to asking them what they think they might do or might like.
Let’s go back to my bicycle light again. I’m going to hypothesize around what happened. The designers knew they were designing a light. They decided on some features — it’s possible they even asked customers what features they’d like — and they decided the light should have three modes: blink (for visibility and longer battery life), steady/low beam, and steady/high beam. They explored the interface — how do you use a single button to turn it on/off and to cycle through the three modes? The single button may come from a cost constraint. The flat, rubber button may have been an attempt to waterproof the light for riding in the rain. But did they observe real customers actually using the product? Not just in a lab setting, but in the real-world, during a typical day? Here in the States, in the late Fall, daylight saving ends and suddenly we’re all biking home in the dark. This is the time of the year that I start using my bike light. And because of the colder weather, I’m usually wearing gloves. If they had observed customers like me, in everyday conditions, they would have seen how hard it is to press that button with gloves on. And they would have seen me cursing under my breath, vowing to never buy a light from them again.
I think the best products make their customers feel smart. When you’re building complex technology products, if you do a bad job with the User Experience, the customer will blame themselves, “I suck at computers.” But it’s not their fault, it’s yours. And no one wants to keep using a product that makes them feel dumb. Frustration, hacks, and work-arounds are all super valuable insights. These are signals that a need that’s not being met. When I used Sugru to make the button easier to push, this was a work-around that signaled a need was not being met.
The key is to learn who your customer is, and to build empathy for them. Let that shape your product.
EW: How do you extend User Experience to the Pinoccio shields that are being developed?
SC: We talk to customers, we try to identify pain points that they’ve experienced with existing tools out there. We also talk to them about what they’re planning on building with Pinoccio. So, we just sent out a survey to our IndieGogo campaign funders asking them what their first Pinoccio project would be. Their answers will inform which shields we produce first. Then, once we have some shields produced, we’ll conduct qualitative research — observe actual customers using them during a typical day, in a typical setting. For example, we might go to a Makerspace where we know someone is building a project with Pinoccio, and just be a fly on the wall while they’re working on their project. Where do they get stuck? Where do they feel frustrated, or need help? That will help us refine the experience for the next iteration.
EW: There are many different solutions in the Wireless field, and the networking of objects that communicate wirelessly. What are some of the challenges of the user experience in this area, and what is Pinoccio doing to help users in this area?
SC: I think to-date, most solutions out there are either (1) so technical that only deep geeks can make use of them, or (2) they’re user-friendly but they’re constrained to a very specific use case, like home automation.
Our challenge is to build an extensible enough system that can support a variety of use cases, a robust enough system that we don’t lose the interest of those deep geeks, and yet still offer something that is easy for less technical folks to understand and use. For that final piece, we’ll be building a series of web-based tools that will help get those less technical folks up and running quickly and easily.
EW: You and Eric Jennings are located in different parts of the country, yet you have a start-up company together. What are the tools that you use to work together?
SC: Yep, Eric’s in Reno, and I’m in Ann Arbor. Eric and I use a number of tools, and have found a set up that works really well for us. We usually have IM running in the background, and ping each other throughout the day. We also do a daily Google Hangout — basically our “Stand Up” meeting in the Scrum parlance. Because we’re a young company, we’re happy to let these calls go long, and meander from detailed product decisions, all the way to long-term roadmap stuff.
We use Git for collaborating on code. We also have an internal documentation site that we use for asynchronous communication. It’s just a WordPress install running the P2 theme — it’s well-suited for short updates that can grow organically into longer discussions. We can archive pages that have evergreen info, and can easily search for and reference them later:
http://wordpress.org/extend/themes/p2
EW: What are your future goals with Pinoccio?
SC: I want Pinoccio to become just another tool in the average person’s workshop, makerspace, or art studio, sitting there right next to the duct tape. When they have an idea, they’ll grab a couple of Pinoccios and quickly throw together a prototype. I want this to feel totally unremarkable. Pinoccio is just another tool at their disposal that expands their capabilities. The object — the board itself — is less important. What’s important is that it enables them to build what they want to build, and it makes them feel smart, industrious, and clever (which they are!).
Like this:
Like Loading...
Atmel | Bits & Pieces 