Adaptive Path Blog

Over the last year and a half, Kim Lenox and I have been teaching the Interaction Design day at UX Intensive. But since I’m leaving Adaptive Path, the Copenhagen event is the last chance you’ll have to see me teach this workshop. Use the code BLOG and get 10% off! (Prices go up after September 30.)

Like I’ve said in the past, I’m really proud of this workshop, especially because we’re iterated on it so much and gotten it to a place where it is fun and useful for our attendees.

The workshop is completely different than the one we presented in Amsterdam only a year ago: it’s changed from a mostly lecture day to a hands-on, design-studio-like experience, complete with crits, exacto blades, and 100+ designers sketching, modeling, and concepting all in one room. It’s great fun and exhausting, and the perfect way to end the week.

Of course, if you can’t make it to Copenhagen, Kim and some of my other AP colleagues will be teaching UX Intensive: Austin in December.

It’s not hard to like a book on web forms that starts with the simple truth: “Forms suck.” Luke Wroblewski’s Web Form Design: Filling in the Blanks is quite a good book, filled with practical advice told in an engaging manner. I can’t imagine any serious web interaction designer not having it on her bookshelf, although it doesn’t get into much beyond basic-HTML web forms. If you want detail on complex Flash or Ajax applications, you should look elsewhere.

Wroblewski tackles head-on the age-old question “Where does the label for the input field go?” that seems to arise ever few months on every web design mailing list I’ve ever ever been on. Hopefully Web Form Design will end that discussion once and for all.

The “Best Practices” sections at the end of each chapter are a really great resource, hammering home the points of each chapter. These alone are nearly worth the price of the book.

I like too that Wroblewski devotes sections to three areas that are so often neglected: help, errors, and confirmations. Poorly done, each of these can greatly affect the overall usability of forms (and any products really).

Back when I was doing web applications that were all form-based, I would have killed for this book. If you are doing anything resembling ecommerce, registrations, and account management online, this book is for you. Recommended.

When I first started at Adaptive Path, one of the many striking things about how different Adaptive Path is from most other companies was explained to me by then-CEO Janice Fraser. “When we set up Adaptive Path,” she said, “We wanted the company and its mission of improving the lives of people through good design to inspire and spawn other companies, both from people outside the company, as well as from those inside. One measure of our success is going to be those other companies. It would be great if we had hundreds of Adaptive Paths.”

Three years later, I’m taking her directive (which she took herself by starting Emmet Labs) and starting my own design firm with some partners: Kicker Studio.

Kicker will focus on designing interactive objects such as appliances, consumer electronics, and devices. (We won’t be doing much web work; Adaptive Path is too good at it!) We’ll be working mostly at the intersection of interaction, industrial, visual design to create physical products and environments that redefine their categories. (Of course, this includes my current passion for touchscreens and other gestural interfaces.)

I plan on relishing my remaining time here at Adaptive Path, even though I know with a pang in my heart the end is coming, and soon. I’ve worked here longer than any place I’ve ever worked. Here, I learned everything I know about running a design consultancy, and, truthfully, a lot of what I know about being a designer in general. It was here I sharpened my interaction design and product strategy skills, as well as honing my speaking and writing chops. Here, I was challenged and re-challenged to really think about the beliefs I held about design and about being a designer. And it was here I made many colleagues and friends who showed me every day what being in this business should be like: inspiring work, joyful play, and always, always, the search for the best idea.

These are the things I will carry with me.

Light Sensor Triggers LEDs

Originally uploaded by odannyboy

While working my way through the Making Things Talk book, I hit a wall when it started to get into electronics. I had to stop and read Physical Computing and go through some basic Arduino tutorials just so I could understand what in the heck was going on. I had no idea what a basic circuit was, or how a switch worked, and especially not how to read an electronics schematic. A bunch of reading and some experimenting later, I have a much better handle on that stuff. Enough to be dangerous, probably, but at least enough to continue.

The next thing I wanted to do was hook up a sensor to the Arduino board and just see what it did. I had a light sensor laying around, so I plugged that in and found a simple piece of code that basically just reads and reports the data coming in from the sensor. I put that into the Arduino programming environment and ran it.

What I got back was a simple, rapid string of numbers ranging from 520 (when the sensor was covered by my hand and thus in the dark) to 600 (when the sensor was in the full light). What these numbers mean, I have no idea, nor does it really matter very much, I suppose. At least not for playing around.

I wanted to then have the sensor do something other than tell me the data, so I added a little bit of code (from an earlier program I’d done based on a tutorial), that made two LED lights light up based on the sensor reading. Red for dim light, blue for bright light. Any number below 530 made the red LED turn on, anything about 560 makes the blue light turn on. And, voila, I had a sensor that controlled some lights. Definitely not brain surgery, but fun, and it is, I think, as simple as it is, a great step towards a bigger world for me.

Next up: a more complicated response to sensor data…

Arduino Light Box

Originally uploaded by odannyboy

Considering that at the start of the week, I knew next to nothing about electronics, I’m pretty pleased with how the week ended up.

After getting stuck on the basic electronics at the end of Chapter 1 of Making Things Talk, I worked my way though most of some Arduino tutorials while reading up on electronics in Physical Computing. I feel like I can at least navigate my way around a breadboard now and make some simple stuff. There is obviously still a ton to learn, but I feel like I’m moving forward in a positive way–especially since several days ago I despaired about ever picking this up.

Next up is adding some sensors and switches. Now that I can make art (of a crude sort), I want to make something more interactive. Stay tuned.

Over the last several years, Adaptive Path’s business has expanded from mostly web work to a mix of web, mobile, medical devices, and consumer electronics. As our business has changed, our skills have needed to change along with it. Part of that change is gaining a comfort, understanding, and hands-on knowledge of subjects that didn’t used to be part of our vocabulary: electronics, programming, and industrial design, just to name a few.

Adaptive Path’s Interaction Design Lab
Originally uploaded by odannyboy

So as part of expanding our skills, I went and set up the beginning of an interaction design lab so that our designers had a place to work and tools to play with. I bought some basic tools like a soldering gun, some screwdrivers, wire cutters, etc. I also bought an Arduino Starter Pack and a bunch of sensors, some buttons, resistors. Other contributions made their way to the lab: our One Laptop Per Child XO machine, an old Chumby, and a touchscreen kit from Synaptics. It’s not much, but it is a start.

The most important contributions were from books though. I donated my copy of Brendan Dawes’ Analog In, Digital Out and purchased the two definitive books: Physical Computing and Making Things Talk.

Then I started playing.

I started working my way through Chapter 1 of Making Things Talk: downloading the software necessary to tinker with with the Arduino microprocessor. Since I learned Processing in grad school (under the patient tutelage of Golan Levin), the programming part wasn’t hard to pick up. I was able to pretty quickly make an LED light up and blink. (“If it lights up, it’s art. If it blinks, it’s interaction design.”)

But then I hit a roadblock. Near the end of Chapter 1 of Making Things Talk, which up until then had done a great job of handholding through the initial code and set up, suddenly stopped the handholding when it came to electronics and working with the physical components. So I had to put that book down and pick up Physical Computing to brush up on that, as well as start working my way through some online tutorials like the set of Arduino Tutorials.

I’ll let you know how it goes.

About a year and a half ago, when I first started thinking about the material that would eventually become UX Intensive: Interaction Design, I wondered what it was that helped designers make those leaps of faith, the great guesses, that we have to make on projects. So I came up with this talk, How to Make Good Design Decisions.

| View | Upload your own

UX Intensive Interaction Design no longer contains this material, but it is still interesting nonetheless. I hope you enjoy it.

I was having a conversation yesterday and mentioned that I occasionally designed mobile phones. The woman I was talking to then proceeded to tell me about the big problem with her phone, that sometimes when she talked, her face hit the buttons and caused the phone to start dialing or beeping and generally disrupting the call. I started to say, “Well, that’s really an industrial design problem…” but caught myself. Maybe it was unavoidable from an ID standpoint. Perhaps they didn’t have the manufacturing budget for better buttons, for instance. Maybe there was something that could be done from the interaction design side, like, say, making it difficult for the pressed keys to do much while a call is in progress.

Each discipline can only go so far with the constraints they work under, and we have to watch each other’s backs and cover for the flaws of each other. Users don’t care whose fault it is that a product works poorly, only that it works poorly. All the disciplines need work together to figure out solutions to product flaws, with visual, interaction, and industrial design blending their strengths together. The visual design should make the interaction design look good, which in turn makes the industrial design look good, which makes the visual design look good. (Mix up the order as you will.) Focusing on the connective tissue between disciplines makes products holistic.

This is the essence of experience design.

It’s hard to believe that iTunes Music Store just turned five years old yesterday, that there was a time (for two years!) that the iPod (iTunes’ better-looking older sibling, the Marcia to its Jan) relied on either users slowly converting all their analog CDs to digital, or simply stealing music online.

While iPod gets all the press and adoration, it seems clear that iTunes, for all its faults, is the little app that could. iTunes is the secret sauce of the iPod experience, and the music store is, if not at the center, than at least an incredible piece of that. Imagine trying to put a major ecommerce store in the middle of another application (Word, Photoshop, etc.) and it becomes clear marvel that is iTunes Music Store.

Of course, the store itself is the tip of the iceberg when it comes to that marvel. Were it not for the amazing technical and business infrastructure backstage (which remains (as it should) mostly invisible), we’d be downloading donated MP3s. Slowly. And forget about movies, TV, podcasts, etc. The store has expanded so that the “music” in iTunes Music Store seems almost silly. iTunes Media Store is more like it. But I quibble.

Happy fifth birthday! You don’t look a day over four. Now could you please go get Twin Peaks for me?

It’s easy to forget when hearing someone give a presentation that the talk is a product too. And like products, the designer doesn’t always know what’s going to happen when the talk meets the users (the audience). Sometimes it works, sometimes it doesn’t. And like a product, good designers go back and revise the beta. Put out a better version.

This is a long preamble to saying that Kim Lenox and me have taught the interaction design day at UX Intensive four times now: in Chicago, Amsterdam, Vancouver, and San Francisco and each time was different. We’ve spent the last year tweaking the content until we (and the audience) were happy with it. As it turns out, it’s tricky to teach interaction design in a day. We went from a nearly all-lecture day to one that is mostly a hands-on, activity-centered workshop that tries to create a studio environment. It even requires having a first-aid kit on hand! I’m really happy how the day has evolved.

If you are interested in learning (or brushing up on your existing) IxD skillz, we hope you’ll join us at UX Intensive Minneapolis in June. Use the discount code BLOG and get 10% off admission!