Part 3/8: From Idea to Prototype
Turning a Hardware Idea into Hardware
We (Senic YC S13) are a hardware startup dedicated to making the interactions between humans and technology more seamless and natural. We want to share our experience making our first product, Nuimo through an 8 part series “Building a Hardware Startup”.
This is Part 3/8 in the series, please check back for Part 4 on using Nuimo with Arduino.
Products start with an idea — right? That’s what we thought. But how does that idea become a prototype, and is your idea worthy of being more than just an idea? The answer is simple: you don’t know…yet.
We learned that developing a hardware prototype is a long process of building and user testing to make sure that you're making something that people want to buy. This process usually takes at least six months to complete for most small teams and generally takes place in roughly four parts:
1. Validating an Idea
2. User Testing
3. Prototyping
4. Final Design Decisions
Validating your idea, user testing and building should be three tightly linked challenges that you address in tandem during your prototyping phase. We have written this post to shed some light on what worked for us while we were building and our biggest learnings during the prototyping phase of our product.
1. Validating an Idea.
Our idea was born the way most ideas are born. We felt a problem that we wanted to solve for ourselves and we hoped other people would like our solution enough to buy it.
We are a group of friends that use tools like Adobe Premiere and CAD software on a daily basis. We're also among the early adopters of smart home devices like smartthings or LifX. We are really excited about what is happening in the IoT space, but also critical. While we loved the products that were showing up on crowdfunding sites and from companies, using the devices was still a pain point for us. Even with our very different backgrounds, there was a strong common interest in how interfaces could better suit each of our needs — this interest evolved into our idea for a product.
Before starting our startup, we had been experimenting with new concepts for interfaces in our own ways. Our Chief Designer, Felix had been building alternative tools for tangible and multi-sensory inputs that gave the user more natural control over 3D modelling software.
As a designer, he was constantly asking why are things the way they are - and we began to discuss together why interacting with software and hardware was so time consuming — why it couldn’t feel as natural as playing a musical instrument. This is where our idea for Nuimo started.
Problem Hypothesis
In the beginning, our idea was a just simple concept. We wanted to create an instant and natural way to interact, but we had no idea if this was a need or concern for anyone but ourselves. Since we couldn't spend lots of time and money on developing something nobody wanted — so we set off to validate our idea.
We learned that the number 1 reason startups fail is because they make something people don't want. In order to find out if other people identified with our problem, we treated our idea as a problem hypothesis to be tested with real people. Much of this testing was systematically done with a validation board. Then we started calling friends or walking into cafes and asking random people questions about their usage of software and smart devices to get some insights.
We were amazed by how helpful people are if you simply ask them to talk with you. After 30 or so of these impromptu interviews, it was clear that the problem affected more than just us. We knew at this point that the idea had enough potential to begin the first stages of development.
Committing to the idea was step zero, the next (even larger) problem was that we didn’t have a clear picture of what the solution would look like yet. Overwhelmed with a million possibilities of how it should look, feel and function — whether it should be round or rectangular? We had to break down all of these decisions and begin to solve them individually and guide the prototype toward a unified product. We started an experimental cycle of building and user testing (10 cycles and 4 months of work) until we began to hone in on a viable solution.
2. User Testing
Up until this point not a single thing had been built and not one line of code written. We had too many questions to answer first including things like: What shape should it have? How big should it be? Should it be wireless? How many controls should it have? etc. The answers to these questions were so fundamental to the future development that we couldn't move on without making some preliminary decisions.
We started off extremely simple — sketches, simple materials, chunks of play dough that people could shape themselves. These low fidelity prototypes worked perfectly for starting conversations with our users and answering basic questions.
We learned that if you show people something developed, it’s a let-down because they expect too much. If you give them something that clearly doesn't work it sparks their imagination to think freely about the possibilities, a key moment in this phase. Instead of focusing on what the prototype can’t do, the user will share their own ideas for the product and lead the conversation about the future they see.
From there, the simple models gained complexity, allowing us to test different form factors and their related functionalities.
How to Find Users
User testing should be done early and often in the product development cycle. As soon as we had a direction for our initial idea, we set off to user test asking anyone and everyone we could find what they thought. Where did we find these people? Everywhere.
Identify your user groups, find out where they hang out, then go talk to them.
Our early users were a lot like us, digital natives between 20–40 years old. We found them at coworking spaces, cafes, meetups, in the park. As the process went on we refined the market we would looking to tap into and became more strategic about how to get feedback from our potential user groups.
After our crowdfunding campaign we got our most outspoken and useful group of users — the backers from our Indiegogo. We took advantage of their knowledge and enthusiasm about the project meeting with 50+ of them in person, making a private facebook group to ask them for advice and surveying them about everything from integrations to names of the product.
These relationships are incredibly valuable to us because they not only helped build the product — they were also our first customers.
How to Get the Most Out of Users
Asking for user feedback sounds simple, but there are a million ways to approach it — and some better than others. A few tips about asking groups of users for feedback can turn lengthy meandering conversations into goal-oriented, actionable feedback.
When you ask for feedback keep in mind:
- You shouldn't take feedback at face value — read between the lines and observe their behavior in addition to what they say.
- Watch for patterns in what people say, not individual comments.
- Confirm something with > 7 people before you make an assumption about its validity.
- Ask the broad and open questions, including obvious things like “How does it feel” “How does it look to you”
- Test hypotheses separately. Treat each one as a variable to be changed and individually considered (size, material, shape, etc)
- Don’t have something too polished, if the prototype is too advanced people have expectations that get in the way of good feedback.
- Test even the most basic assumptions.
2. Prototyping
After our first set of interviews we had a first rough idea of the requirements of the device and we could start prototyping. The key here is to continue treating each decision like a hypothesis. Whatever you build might be the right solution or not, but it’s the best way to make small calculated steps toward a final prototype.
Bolt recommends building 1 prototype per week. However to build at this pace takes some planning. Here are a few tips about how to prototype smart and quickly.
Electrical and Mechanical Components
To increase the pace of prototype building, we used standard components that have strong online support.
To work out the basic concept, we started with an Arduino board. Using Arduino was low-cost and open source meaning that it came with a strong online community with tutorials and open source code. Using Arduino or Raspberry Pi is only viable for the prototyping phase, but is a smart move so you can source parts quickly and sketch out a concept for the electronics fast.
Likewise, we recommend using standard and supported components whenever possible. For electronics, ordering parts from SparkFun, Seed Studio, Adafruit or TinkerSoup is great because they have a huge selection and ship fast.
For mechanical parts we use our local construction market or websites like McMaster-Carr.
Fast Prototyping Tools
You don’t need much to get started with electronics. By just investing a few hundred bucks into tools like a soldering iron or a monthly membership to a maker or hackerspace like Techshop, you can begin to create hardware.
One of the things we invested money into was a 3D printer (although you can also get access through a Fab Lab). Using a 3D printer to prototype allows you to quickly:
1. Test form factors for your design
2. Print parts to see if they fit before purchasing (saving time and money)
3. Build fast prototypes variations that you can test with your users.
Another great way to get access tools is to share them with a larger community. One of the main reason we love hardware is because it brings people together out of necessity. Prototyping is much easier with the support of a community to help and share knowledge. We have friends who we visit to do some CNC milling, or call us because they need a 3D print. We recommend getting involved in the hardware community, locally or online. It’s really helpful and a lot of fun to share ideas.
Partial Prototypes with Specific Goals
Once the first few prototypes have been built, they tend to move into a more defined space and the process hits a cyclical stride. With complex consumer electronics, it’s difficult to prototype all aspects of the product at once. When people suggest building one prototype per week they generally mean that you should be looking to improve at least one aspect of your design, mechanics or electronics — hopefully multiple each time returning to your users for feedback.
We built dozens of prototypes with different purposes, here are just a few types:
Mechanical Prototypes were extremely important to us because first and foremost our product is about touch. Finding the perfect size, weight and feel of the ring would be deciding factors for the success of the product. We made dozens and dozens of mockups to test out each minute detail of the feel and mechanical movement of the Nuimo.
Electronic Prototypes were key in the process. In addition to trying out new functions, electronic mockups were also important for showing to mentors and engineers to get valuable feedback on the finer technical details when deciding how to optimize the design of our device.
Visual Mockups are important both for decision making in our design process but also for the sake of showing investors, backers and friends. One of the biggest challenges in designing a physical product is making sure that your vision for the aesthetic of the device is aligned with the physical requirements of it’s mechanical and electronic components. In order to show potential users what the final device would look and feel like- we made visual mockups to make our vision clear to everyone we talked with.
Proof of Concept was important particularly for more formal conversations with press, investors or mentors to show the entire experience of the device. We found that even before we had designed the final PCB we could use a larger version of the device to showcase the functionality and promote our product before the crowdfunding campaign.
Final Prototypes should have all of the functionality that the final device will have when manufactured at scale. Be warned however, this prototype will likely be completely reconfigured during the design for manufacturing phase (which we will discuss in part 5).
4. Final Design Decisions
When you finalize a certain function or aspect of the device, a general rule of thumb is to make sure that of the users you talk to 70% have are positive about your product and are willing to buy. If you can get to this margin, then you have something that is sellable.
Another approach is to use the Net Promoter Score (NPS) which asks “How likely are you to recommend this product to a friend?” Ideally, the feedback should be around 70 for a successful product.
It’s difficult to decide when exactly the user feedback-build cycle is complete. As with any design problem, factors like time and money may make this decision for you. Deciding when your prototype is final is an intuitive decision — eventually you will take the leap of faith and move on to the next step of production.
At the end of this process, you should have a working prototype that solves the problem you started with. This is a good time to take a breath, maybe scream with joy and get ready for the really hard part to start. Moving from a simple prototype to a design that can be manufactured at scale while maintaining quality is a completely different animal that we will discuss in Part 5 of our series.
This is Part 3/8 in the series “Building a Hardware Startup.” Check back for Part 4 about connecting Nuimo to Arduino.
Who Are We?
We are Senic, a Berlin-based hardware and software startup building our first product — the Nuimo controller. We are a team of designers and engineers dedicated to building the future of interface for the home and office.
Follow us on: Newsletter | Facebook | Twitter | Instagram | YouTube
