Design Like You Can’t Feel Fear
by David Mayman and Tim Meador —Method San Francisco
A little bit about us — we are two multi-faceted designers with backgrounds in graphic design, architecture, software development, and hardware prototyping with a bad case of “inability to feel fear”. By some twist of fate, we both ended up at Method, where we get to tackle problems ranging from an in-flight experience to how to get people to take their medications. Method’s roots are in brand and have spread to digital products & services over the years, and collectively we see a future where digital communication becomes intertwined with our physical environment.
Though we live in a physical world, much of the information that we create and receive is delivered through digital technology. We’ve entered this sort of ‘Stranger Things’ era of digital technology, where the alternate reality has the potential to be awesome (not necessarily monster scary) but needs to be managed and integrated into our everyday real reality. So, we believe that one of our most important missions as designers is to know how to design in concert with the physical. Let’s make the upside down and the right side up live in harmony.
Because we are a group of makers, we needed to do some experimenting to test these transition points. Is it really possible to show data sets in the physical world? What if they were integrated into objects as common as a houseplant? How would people react to that? As a principle, we learn by doing, so we designed and developed five data-driven physical experiments to see how far we could push our ideas. We showcased them at an event we called “Surrounded by Data” as part of SF Design Week to get some honest (really really honest) feedback from our fellow design community.
And what we learned was that yes, we could push it really far; that no, going analog isn’t scary to people; and that this is where a lot of people believe the digital revolution is trending.
We need to keep exploring, and when you move beyond the screen and start working with data sets in the physical world, that process can seem daunting. We want to help make it a little bit easier.
Here’s what we learned:
Have a Vision
It’s important to establish a very clear vision of what you’re trying to achieve before diving in. This can and will change throughout the project (and by all means, stay flexible), but it’s crucial to establish a belief, a vision, and a hypothesis. What are the qualities of success? How should it feel? Behave? How is it used over time? Answering these questions will become your guiding light when things get rough.
Know your Why
You should ask yourself “why am I doing this?” and be able to have a pretty good answer.
Have a Clear Hypothesis
Start making predictions early on regarding the tools, materials, processes, and eventual integrations you’ll need over the course of the project. It’s okay not to know every detail, but the more comfortable you feel early on, the easier it is to foresee problems. It’s also important to know and admit when you are just guessing.
Before building anything for Surrounded by Data, we spent months brainstorming, developing our vision and rationale, and weeding through concepts. We established a vision to build a set of simple, beautiful, abstract physical objects that inherit meaning only by those that initiate them. Driven by the potential of the role of data within our surroundings, we wanted to communicate information through an emotional reaction rather than raw data. Why? Because raw data is hard for most people to understand. That’s why the interface of the Fitbit is so popular right? So we took that raw data and made the output a beautiful physical object. Each object in the set conveyed meaning by playing with a different group of physical attributes such as movement, spatial relationships, or light and shadow. We hypothesized that the expression of information through these rich, natural forms would garner a more emotional connection with the user.
For Canvas, we were enamored with idea of expressing an insight through the subtlety of one simple moving spline. For Connections, we were interested using a group of objects representative of a person to visualize what can’t easily be expressed verbally. For Chronos, we were curious how the system we use to understand time alters our interpretation of it, and how we might create a more natural and personal representation of time. We wanted to measure time with moments rather than minutes.
Break the problem into smaller pieces
We picked this one up right out of our experience with coding. Every big unknown problem is just a series of many smaller problems. The smaller the problem, the easier it is to find a solution. We see this a lot in coding projects. There are many workflows built on modularizing code, both for ease of development and reusability. We took a similar approach in our process. We broke each experiment into achievable bits, some we knew how to do and others we didn’t. That let us work systematically, solving mini problems before trying to put them together.
Our experiments called for a considerable amount of hardware-software communication, ranging from low to high level. For Canvas, we wanted to allow two users to approach the installation and show how their step count data maps together to display a real data set they’re already carrying around. We broke the communication problem up into two separate paths — device control (high level) and hardware control (low level).
Warning: We’re going to get a little nerdy here.
High Level
We used an Intel Edison embedded in Canvas to host a node.js server over a public WiFi network we created. Using a Sockets protocol, the Edison connected to an iOS app we designed and had visitors install. When users approached and connected to Canvas, their iPhones sent the last week of step count data to the Edison, which parsed through and generated a series of coordinates.
Low Level
The Edison then sent these coordinates out to an Arduino Mega through serial. The Arduino controls the position of 7 stepper motors using a custom library we designed for speed and noise reduction (they can get real loud!). It also illuminated Canvas based on a color assigned to the user by the Edison. The Arduino keeps track of the position of every motor to ensure reliable repositioning. We even built in limit switches on top and bottom to tell the Arduino it’s gone too low or too high in case anything slips.
This marriage of low level and high level code required a hefty amount of coordination. It worked really well to think of it split like this, and to have each of us own a different portion of the work.
Set up the right environment
We really can’t stress this one enough. Having the right tools, space, and materials for a project saves a ton of time and stress. At Method, we have a section of our office devoted to these types of projects that we call the Hackspace. It’s a space we built from scratch to support physical making.
Most hardware prototyping requires a few (or many) very specific parts that need to be tested together, the approach you originally thought was going to work typically doesn’t pan out. We had the vision for a space that has what you need before you knew you needed it. Of course it isn’t perfect, but we’re constantly working on it.
Setting up this ideal environment is an impossible and endless task, but each project you do gets you a bit closer. As you’re working, take a moment to think about what would make your life “so much f*@#ing easier right now” and consider putting the effort into it! Or at least writing it down for next time…
Having the appropriate tools can’t be underestimated. You’ve heard this a hundred times, but it’s damn true. The right tool for the job will definitely save you time. Do it. When you’re planning your budget, make sure to include necessary tools in with the materials. There are always many ways do a single task, so try to expand your idea of what a necessary tool is. Sometimes it may be a simple hand tool, and other times it may be something more flexible like a 3D printer.
Do Your Research
Sure, your vision is one-a-kind, never been done before, but chances are, once you’ve broken it into smaller problems, somebody has done a piece of what you’re trying to do — probably a lot better than your first guess at it too. Knowing how to do research and learn from the collective knowledge of online communities will propel you lightyears towards your goal. As far as we’re concerned, it’s the only way to go. Check out sites like Instructables, Make, Bildr, and Arduino, and obviously Google.
Many times during planning and construction we found ourselves having an idea of a type of mechanism, part, or process, but not knowing what to call it. We found that everything has a name. Using sites like McMaster-Carr or even Amazon to determine what that spinny uppy-downy thingy is called is really helpful in finding similar things, or finding cheaper and more efficient ways of achieving a certain goal.
Prototype Early and Often
It’s important to depart from the whiteboard as soon as you can and start testing things at real scale with real (or real-ish) parts. Make your prototypes behave like the real thing as best as you can before diving into the fabrication details. You may need to change your approach drastically once you see how an idea plays out.
For Canvas, we broke it up early on into two different paths — one aesthetic prototype to test the look of the final intended outcome of stretched fabric over a seamless spline, and one mechanical prototype to test accurate, synced mechanical motion of 7 vertical pulley systems. We ended up drastically changing our approach about 10 times before combining the two prototypes in the final assembly.
After trying every cable idea we could think of, we got the idea of using an actual measuring tape (while holding an actual measuring tape and saying “I wish we had something flat and retractable like a measuring tape”). We used the aesthetic prototype to test the measuring tape approach, and discovered a new problem of friction building up on the tape. We eventually introduced 6 bearings on each vertical node to allow them to move freely in every axis, using the 3D printer to create a single mount that held each bearing precisely as needed.
We also used 3D printing to make up for the slight inconsistencies in the spacing of the linear rods due to our maybe less than perfect woodworking (hey nobody’s perfect). Once the core frame was built and rods were mounted, we measured each placement to thousandth of an inch and printed a slightly different mount for each position, giving us silky smooth frictionless motion. Yeah, we couldn’t believe that worked either.
Each problem we solved introduced a new set of problems, which we would not have discovered without really making it. Interaction with physical (and digital) interfaces has a subtlety that is not easy to predict. Testing it in action, even if it’s faked, allows you to gather valuable feedback from yourself and others.
Leverage your team’s diversity
A diverse team will help you generate better ideas and iterate faster. Keep learning from each other throughout your project, and celebrate the differences in your skill sets, approaches, and beliefs. Divvying up the work by team members’ backgrounds and strengths helps give a sense of ownership to everyone, and adds more depth to your project.
In addition to us hacksters, our team consisted of 6 researchers, visual designers, and interaction designers that all worked together to conceptualize and realize these experiments.
Sometimes the “hacky” way isn’t the right way
It pains us to say it, but there’s a certain point where you have to admit defeat and buy the thing that does what you’re looking for, even if it is a bit expensive and you think you can make one yourself. Before you get hacky, try to think about how questionable your approach is. Chances are you’ll need to test it before you really know, but you can probably predict how much effort you’ll need to get to that point. You’ll probably need at least double that time, so ask yourself: is my time worth more or less than the cost of the item?
For Connections, we ran into an issue with the torque of the motors being too weak to lift the lanterns. After doing some research, we found the plans to a laser-cut planetary gearbox. We were of course enamored. We wasted about a week and a half to develop a working prototype that did eventually work, though finicky. Shelling out the $200 of metal gearboxes would have saved us a bunch of time and stress.
Project budgets might not be within your control, but it’s important to be realistic with what you need. Hardware prototyping can be more expensive than you think, and it’s crucial to be prepared with the right resources — money being one of them.
You don’t have to know the answer
If you take one thing away from our experience, this is it: Don’t expect yourself to have a flat out answer for how to achieve your goal — focus on having the drive to figure it out. Trust yourself. Breaking it into small pieces, doing your research, and tapping into as many resources as you can will take you as far as you want to go. Even experienced hardware prototypers work like this. The prototyping process is filled with moments of feeling unqualified, inexperienced, and perplexed. Celebrate that exploration and curiosity above all else. And beer. Beer helps.
To learn more about Method please visit www.method.com.
