“Standing still is the fastest way of moving backwards in a rapidly changing world.”
On January 9, 2007, a man quietly walked onto a stage and changed the course of technological history. He announced that his company was about to launch a product that would forever change the way we communicate.
Then, in a dramatic fashion, he held up a phone he and his company had been working on for over five years. Reporters furiously captured images of the device, quickly sending them to every corner of the world. The man demonstrated how you could zoom out on images by making a pinching gesture and navigate your music library by swiping a single finger across the screen. He walked through various applications: a notepad, calendar, compass, and detailed maps. No one had seen anything like it. The phone seemed like a product of science fiction. But it was very real, and all of it was small enough to fit into your pocket.
Back then, I worked as a web programmer for a children’s hospital. I remember sitting at my desk watching the demonstration via a live blog and waiting what seemed like forever for the images to stream to my computer. As soon as I saw the first picture of the iPhone, I remember feeling as though I’d just witnessed something significant. At that moment, I hadn’t yet realized the extent of the iPhone’s impact on our industry; but as a developer, I could see that the bar had been raised. I knew the days of getting a pass for cluttered user interface (UI) and confusing layouts were over.
My users were going to expect more.
It wasn’t enough that my applications had fast load times or a laundry list of features. My users were going to want the iPhone. Not just the product specifically, but what it represented. It was intuitive, minimal, and engaging; and now my users had a shining example of how everything should work. New forms of interaction were ushered into the conversation, and terms like Multi-Touch and NUI instantly became part of developers’ lingua franca.
A year later, Apple opened the App Store for the iPhone, creating an explosion of application development. Developers began competing in saturated markets where users had thousands of choices, and in most cases, hundreds of thousands. Companies like Google, Microsoft, Facebook, and Amazon were also growing their extensive development platforms.
Today, more and more consumers are purchasing these products and services. They’ve become reliant on them and they bring them into the workplace. IT departments are no longer controlling their environments by issuing phones and computers; the expectation is that all these devices just work on the user’s corporate network. Therefore, the bar has been raised for the enterprise developer, too. Corporate users expect things like company portals and line-of-business applications to be thoughtfully designed and engaging, just like the products they use at home.
So, as developers, how do we cope with all of this?
I have a rather simple presumption. In order to build products that users love, we need to include users in the process of building them. Granted, many might point to Steve Jobs as the antithesis of what I’m suggesting. In a May 1998 article by Bloomberg Business Week, Jobs famously said:
It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
While some of this sentiment may be true, I think we have to be honest with ourselves. Jobs had a unique ability to understand what users wanted, and many of us don’t possess that ability:
We’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users—the users don’t have to come to them, they come to the user.
I don’t believe Jobs could’ve created products that met the “intersection of technology and liberal arts” without understanding the wide spectrum of users’ needs. We can’t build products that “come to the user” if we’re unwilling to come to the user ourselves. While Apple may have an intuitive understanding of human behavior, many developers do not.
However, I do believe this type of intuition can be acquired over time, and the best way to acquire it is by spending time with users.
By collecting feedback and observing their behavior, we can gain valuable insights into building applications they’ll love. Anyone involved in the process of creating an application (not just designers) should be invested in understanding what users need to complete the application’s purpose. It’s more than just graphic design, code, or functionality. It’s the entire team (or just you) continually working to understand the user. Not all of our users’ problems can be solved with code, although I wish they could be; therefore, developers need to take a more holistic approach.
This notion might seem like common sense, but it still amazes me how many developers aren’t taking the time to do this.
Most of my experiences come from working in a community hospital setting. It’s a uniquely different world than other software development environments; however, I still encounter many of the same challenges. In a hospital setting, users are treated just like clients. They make a request for our services, we sit down with them and outline how we plan to help, and then we deliver a product (fingers crossed!) by the agreed upon deadline.
We’ve been able to improve our process by implementing the user-centered design practices outlined in this book. By focusing on usability, we save time and create applications that meet our users’ needs. Although our development environment may be different than yours, you’ll find that the practices detailed in this book can be modified to meet your needs or circumstances.
This book isn’t a lengthy tome on the history or current state of usability. It’s meant to be a collection of sensible tools and methods that you can start implementing today. This isn’t a magical formula that, when applied, produces a perfect application. Ideally, you’ll come away from our discussion with your own views and ideas of how to improve your development process and re-engage your users.
Being a developer myself, I realize that we’re in a nonstop world of ever-changing frameworks, coding languages, and whiz-bang editing tools. It can seem daunting to add more steps to your development life cycle.
However, the methods described in this book are essential in creating a focused and efficient development process. These steps will actually save you time and prevent your projects from heading in the wrong direction.
I know some developers measure a book’s value by its page count, but this book is smaller by design. I’ve done my best to create a high-level overview so you can get started quickly. Be sure to review “The Short Version” at the end of each chapter. These are bulleted lists that summarize the main concepts of each section.
It’s an exciting time to be a developer! There are so many ways we can enrich people’s lives. We have the ability to delight them and change the way they interact with the world and each other. It’s a unique and challenging responsibility.
After our discussion, I hope you’ll have an even greater desire to explore the user experience community. Be sure to check out Chapter 11 for useful links for industry thought-leaders, publications, and products to help you along the way.
Now, let’s get started!