Thoughts and essays from the guy who coined the word "blog."
On June 11, 2010, inspired by my son’s inability to not press the candy-like home button, I wrote a post for Adaptive Path titled, Toddler Mode for iPad.
On June 11, 2012, Apple announced “Guided Access”, which supports turning off the hardware buttons.
At my new company, we would consider that ticket closed.
Over on the Adaptive Path blog, I just posted “Apple iPad and the 3 Waves and 5 C’s of Computing Use” about the evolution of interaction paradigms and the way we use computers. Long-time readers of peterme.com who have steel trap memories will recognize its roots in a 9-year-old peterme.com post, “Way New Interfaces, Revisited.” It’s funny how slowly things actually change.
I’ve got a little series of advice/guidance/wisdom/hubris for interaction design students
I’m very much involved with Adaptive Path’s hiring processes, and as such I see a ton of resumes, peruse a scad of portfolios, and discuss futures with hordes of students soon to be graduating from a range of undergrad and graduate programs. As a “hiring manager,” what interests me most is your work. Do you have the skills to pay the bills, and how comfortable and confident are you when talking about your approach to solving problems?
Among my biggest frustrations is having students walk me through bullshit school projects. Bullshit school projects are those which are solipsistic (solving a problem that a limited set of college students face), and/or uninteresting, and/or overly formal, and/or simply lack meaning. If I’m going to be hiring you to work with clients to help address their challenges, I need to be comfortable that you have an ability to engage in real-world problems.
I think much of the blame for these projects lays at the feet of the teachers, who have ensconced themselves in the academy in order to avoid the real world. But students have a responsibility to demonstrate what they can do in a way that someone who doesn’t know them can understand their thought process, their approach, and their talents.
Perhaps the single best way a student can ensure she is doing relevant work is to take internships at companies. I met one undergrad who has worked with IDEO, Frog, and Nokia, and the work she showed me was largely drawn from these experiences, and gave me the confidence that she could deliver real-world design.
I’m not saying students need to think corporatist. One of my favorite student projects is the redesigned BART kiosk by Ljuba Miljkovic and Ben Cohen. BART didn’t ask them to do this (in fact, it demonstrates that BART unwisely spent money on a user interface so poor it could be vastly improved by two smart college students in a semester), but for a class project they realized it offered a remarkable opportunity. It hit on a real-world pain point (as anyone who has purchased a BART ticket knows), and demonstrated a thoughtful and practical approach.
And it doesn’t need to be a project that appeals to a big audience. As part of his MFA work at CCA, Matthew Baranauskas has done a set of tangible computing projects to create new tools to help mentally challenged folks express themselves in a variety of creative ways. While the number of people who could use these tools is quite limited, by addressing a space very different from his normal context, Matthew demonstrates his skills and vision in such a way that it’s clear how he would approach professional work.
So, if you’re an interaction design student, please don’t do yet another mobile app that helps you and your friends coordinate getting beers (or yet another web app that monitors a building’s energy consumption), or some context-free formal exploration of gestural interfaces, or something that simply demonstrates that you’ve learned a set of methods. Identify an interesting problem *in the world*, and attempt to solve it.
I can finally announce it publicly: I’ve had a Nexus One for the past couple weeks. While I played with it a bit, I never used it extensively, as I didn’t want to put my iPhone’s SIM card in it, and I didn’t have any other SIM cards lying around.
The Nexus One is a perfectly solid offering in this touchscreen-smartphone space. Its interaction and interface design are quite good. I love the Maps app, which essentially can operate just like an in-car turn-by-turn GPS navigation device, with the added benefit of Google Street View, so you can be quite positive your turning at the right spot.
I’m very interested in leaving Apple and AT&T, and the Nexus One could very much be that new phone for me. I am not really reliant on any non-standard iPhone apps, so the transition shouldn’t be too hard. But, at this point, I’m not ready to make the change, for two primary reasons:
All that said, if I could get a $60/mo plan on T-Mobile for the NexusOne (which is what I currently play AT&T, as I’m grandfathered in with my first-gen iPhone), I would have to seriously consider the switch. However, it looks like the minimum price of the necessary T-Mobile plan is $80/mo, which is kind of a non-starter for me. I would even consider $70/mo with unlimited SMS and data.
I am happy that there is now a legitimate competitor to iPhone/AT&T, and one that is not beholden to a particular carrier. I hope this finally leads to some competition in the pricing of service plans.
I had originally planned to speak in SVA’s Interaction Design lecture series yesterday, but had to cancel because I’m needed in the SF Bay Area. So, I thought I might blog the things I would have said
In school, and, well, in most companies, product design and development is approached as a process. The problem with this is that people stop being able to see the forest for the trees — they get so focused on following the process that they lose site of why they’re engaged in the process to begin with.
What’s more important than process is mindset. And when it comes to interaction design, that mindset is having empathy for and understanding your users, and creating something great for them. If you and your colleagues have the right mindset, you’ll likely do the right thing, because you won’t be satisfied until your users are pleased. At UX Week 2009, Aaron Forth, the VP of Product for Mint.com, spoke. (You can see his talk here.) One thing that Aaron points out is that his team didn’t engage in anything resembling a user experience process, but because everybody at the company, from the CEO on down, cared about the user, they weren’t satisfied until they produced great results.
In Jared Spool’s talk “Journey to the Center of Design”, he claims that companies adopting a “user-centered design process’ actually produce less usable designs than those that don’t. What happens is that companies offload critical thinking onto the process, and assume that if they follow the recipe, good things will come out at the other end. It just doesn’t work that way.
Speaking of what comes out at the other end, that’s all that matters. Results and outcomes are what’s important, not the methods you use to get there. If a rigorous UCD process is what gets you to great design, awesome. If sketching on a napkin, then bringing that into Photoshop works, great. The proof of the pudding is in the eating — if people are happy to use the design, and it satisfies whatever tasks/goals/etc they seek to achieve, that’s what matters.
So, at most, use methods and methodologies as a scaffold to help you think and work through your problems. But don’t adhere to a process. Just use whatever works.
I had originally planned to speak in SVA’s Interaction Design lecture series today, but had to cancel because I’m needed in the SF Bay Area. So, I thought I might blog the things I would have said
This is a subject I’ve talked about at length before, perhaps most notably in the essay, “Experience IS the Product… and the only thing users care about”, the slidecast “Experience is the Product”, and it was a main theme in Adaptive Path’s book Subject to Change. So I won’t go into in detail again, but it’s worth acknowledging that most people still approach product development very much from a features-and-functionality standpoint, and most design work gets so focused on the specific outcome that the designers lose sight of the ecosystem in which their work must fit.
In this increasingly complex world, product design is really systems design. A number of elements must be marshaled and coordinated. But it doesn’t make sense to design a system for the sake of it.
So, a system to what end?
I would argue, a system to support great experiences for people. And from figuring out how to support the delivery of great experiences, then design the interactions, identify the touchpoints, and build the systems that support that.
Adaptive Path’s latest R&D project has been released: Mobile Literacy, which addresses the design of mobile technology in emerging markets (in our case, rural India).
There’s tons to chew on. I would start with the concepts, the MobilGlyph and Steampunk.
If those intrigue you, then I’d move to the deep research. Our team spent 6 weeks in the Kutch district of Western India to understand the how uneducated and illiterate peoples use technology, particularly mobile phones, in their lives. A big challenge is that these phones are designed for Western (specifically, northern European) audiences, and many of their assumptions don’t hold true in this area.
The most important thing is to rally others to take part as well. That’s why we’ve made all of our research available, and why we’re sharing the design principles that emerged from that research. We recognize that our concepts are just two of many that could address the challenges of bringing mobile technology to emerging markets. I hope we see many more!
I first saw Siftables at TED 2009, where David Merrill demonstrated them. I immediately tweeted, “Omg. Siftables are awesome. Google it, watch videos. #ted.” Here’s the talk:
My reaction was not unique. David was quite popular for the remainder of the event. There’s something about Siftables that taps into the “Well, duh” reaction, when you see something new that seems so obvious, which feels so inevitable. We had a couple of the folks from Tacolab, the creators of Siftables, over to Adaptive Path a week ago, and since then I’ve been trying to figure out what makes them so special.
We’re in an exciting time in human-computer interaction. There’s a lot of movement to get beyond the keyboard + mouse and towards new methods of interaction and input, whether it’s Wii-motes, iPhone’s touchscreen, or the Microsoft Surface table of CNN’s Magic Wall. And while I’m intrigued by all those tools, Siftables actually opens up a whole new avenue of inquiry.
See, one thing we’re still really stuck on is the Single Screen Interface. All of this activity is still geared toward a single display, whether a TV, mobile device, a computer screen, or a wall. (Seeing Siftables made me only even more frustrated with iPhone, because there’s no reason iPhones shouldn’t be able to directly engage with one another (I mean, even the original Palm Pilots allowed infrared beaming!). Instead, iPhones are isolated, attention-greedy devices.)
Siftables begins to suggest what happens when your computers are small, fast, cheap, and out of control (I very much think of Rodney Brooks’ comments in Errol Morris’ superb film, Fast Cheap and Out of Control.) There’s a whole new opportunity for connection, interaction, swarming, meshing, and emergence.
Importantly, the form of Siftables also speaks to *fun*. They’re blocks, and, as kids know, blocks are fun. The immediate impulse of anyone interacting with Siftables is to *play* with them.
For some reason I can’t quite figure, when I began to think of applications for Siftables, my mind went back, way back, to 1984, and Rocky’s Boots, an educational software title for the Apple II that taught basic computer logic through graphic assemblage of logic circuits. It would be awesome to physically build such circuitry with Siftables, and take advantage of their interactive nature. I then mused on whether you could program Siftables with a visual programming language on the Siftables, and then my head went all recursive and I had to do a hard reboot, probably with alcohol.
In conversations and on mailing lists addressing the design of interactive media, I’ve found myself growing uneasy with just how little understanding most people practicing in the field have of how they are influenced by the various theories that undergird are standard practice. I think it can be problematic that so people are working in the context of these theories don’t understand how the theories’ assumptions are coloring their approaches.
What do I mean by theory? Theory is a robust conceptual framework that undergirds a practice. Standard thoughtful practice of design for interactive media is predicated on a cobbled-together set of theories, most of them coming out of the HCI community, which has been heavily influenced by cognitive psychology (think Don Norman’s Design of Everyday Things). So you have things like distributed cognition, perception, attention, etc. Cog psych tends to focus on the individual.
Another major influencer is Activity Theory, which I believe gained traction as researchers studied the workplace, and wanted to understand how technology influences groups of people, not just individuals. Since the dawn of the Web, there’s also been significant inroads by the Library and Information Science community (Information retrieval, metadata, etc.).
As experience design leads to people trying to understand more complex situations, we’re seeing folks embrace anthropological and sociological methods… which also have their various theoretical underpinnings, far too numerous to go into here.
I believe that my exposure to and understanding of various theories (not to say I’m an expert in them) has heightened my experience and practice in design for interactive media. But I also know I’m a knowledge wonk who gets off on such things. Still, I think people will perform better when understanding the theoretical constructs in which they operate, so they can appreciate self-imposed arbitrary limits that may not have realized. Pragmatists might take issue, saying that all that matters is practice and results. That might be true if we were designing simpler systems. I think theory gives us tools for making smart heuristic judgments that help manage the complexity inherent in our work.