This past year, I returned to one of my life-long passions: dance. In doing so, I was surprised to find a number of dancers who were also designers and developers. Thinking on this further, I believe there are a few key habits that designers can hone through, or borrow from, dancing.
Developers are constantly making new tools that make it easier for us to get our own job done. There’s always a shiny new framework to try around the corner with a rich and well-documented API. There’s a faster, more idiomatic language coming up that’s just about to break the big 1.0 release. There’s a new software development practice, a new way to run tests, a new tool for team communication and code review. There’s a metric ton of failures, of course, but as a general trend, things just keep getting better — I can happily report that I have never looked a punch card in the eye.
But, unfortunately for us, there’s nothing that necessitates that our users are going to have as wonderful experience using a program as we had writing it. (And, perhaps, fortunately, vice versa.) Joe from HR, logging into $ENTERPRISE WEB APP$ every morning, isn’t going to care about whether the code is pristine. He’s not going to care about whether the original developers used TDD. It could be an app hacked together from an unholy combination of PHP and bash scripting by one cowboy coder over the course of three sleepless, Mountain Dew-filled nights. It could use XML-formatted text files for storing persistent data. None of this is going to directly matter, to the end user. He’s only going to care about whether or not it helps him do his job.
Are preschoolers smarter than college students? When it comes to figuring out gadgets and iPhone apps, it certainly does seem that way sometimes.
I heard an interesting piece on NPR several weeks back about this very issue. Researchers at the University of California, Berkeley, have found that 3- and 4-year-olds use a different process than older children and adults to figure out how things work. In experiments conducted by the researchers, children had to figure out how to operate a specially designed music box. According to the NPR story, “Children try a variety of novel ideas and unusual strategies to get the gadget to go.” For that reason they are often quicker to figure out how novel technologies work.
It’s a well-known fact that many people in the older generation has been struggling with new technologies.
For those of us that work in the software or design industries, it’s easy to take technology for granted. Most of us are “digital natives” — we grew up with electronics, and it can be difficult to set those assumptions aside and design for senior “digital immigrants” who spent most of their lives without any type of digital device.
How Seniors Use Technology
Despite being late adopters of technology, seniors have unique day-to-day needs that modern technology helps them solve. Digital devices help seniors with staying active, keeping in touch with friends and family, and daily medical needs. 76% of all seniors own a desktop computer, and use technology for emailing, social media, keeping track of photos, online shopping, and even gaming. Read more on Creating Accessible Interface Designs for Seniors…
I’ve been spending a lot of time in Chicago lately, and this past week something caught my eye. When you get off the CTA trains, many of the stations have a large granite compass rose inlay on the ground. It’s a fairly handy thing to see in its own right (and they’ve helped me navigate on more than one occasion), but it’s also a great specific example of a really interesting general concept: These physical compass roses are a bridge between the abstract world of the map and the real physical world.
When I started thinking about them in those terms, I realized there are a lot of other great (and some not so great!) examples of the same concept.
There are a few really obvious instances: bar codes (such as UPCs) are a perfect example, but they aren’t really very interesting because the transition between the physical box and the abstract world of the inventory system is not really very smooth. Read more on Connecting Technology to the Real World…
Recently I found myself faced with a new design challenge: to create a digital game interface that uses differentiating hardware and software components to facilitate a fun and social game play experience.
I looked for a framework to help me deconstruct the various aspects of the game into collaborative conversations I can have with client-side engineers, product managers, and marketers. I found the engineers were deeply involved in leveraging the hardware mechanics to design differentiating aspects of the game, while the marketing team was focused on product branding and visual design.
MDA Game Design Framework
I started as many designers do, weeding through the web to withdraw inspiration and artifacts to leverage something that might be pre-existing. That’s when I stumbled on the white paper “MDA: A Formal Approach to Game Design and Game Research” by Robin Hunicke, Marc LeBlanc, and Robert Zubek.
Don’t base your user interface design off of your database design. Your users won’t like it.
That sounds like a silly, obvious platitude, but I’ve seen these sorts of designs much more often than I expect.
When your database has one table for users, one for groups, and one for companies, it’s an easy and obvious solution to create simple CRUD forms to manage the data. Don’t. This is a terrible user experience.
Too frequently I work with applications where I cannot add some entry (e.g. a new user) without going to a different admin panel to create a group or category first. An example of this is the old 37 Signals’ tool Basecamp (this was fixed in their new release a while back, but it was still a problem for a long time). Here’s a screenshot from the old “All People” page:
Building software is an exercise in trade-offs. There is always an abundance of ideas and a shortage of money or time. Working to balance competing constraints is what I do. As a developer, I try to estimate and minimize implementation time without sacrificing quality. As a project lead, I help clients prioritize features to build the most complete product we can for a given budget. But these aren’t the only factors that we need to consider, and I’ve been struggling with what to do about another critical aspect — joy.
My iPhone 5 stopped charging the other day (the Thunderbolt dock failed), so I made a Genius Bar appointment, and they handed me a new phone and sent me on my way. In five minutes I was back up and running as the phone restored itself from my iCloud backup. Though I had 10GB of data to recover, my settings, contacts and text log came down immediately, and (with the exception of my still-downloading apps and content) I had full use of my device. I texted Justin about how thrilled I was with the outcome, and he responded, “It just works.” He’d gone through the exact same experience the week before.
The Secondary Experience
It dawned on me that I’d just had an excellent secondary experience. If the primary experience of a product is its intended use (making calls and using apps, for example), then the secondary experiences are all the functions that support the primary experience (setting up, dealing with problems, etc.). Instead of “just working”, my phone had just broken, and it was the customer service — and a deceptively-simple-feeling backup infrastructure — that had made my day by turning a potentially disruptive event into a painless business transaction. Someone had correctly anticipated the path I would take and had smoothed it out perfectly for me, no doubt at significant development cost.