A Reminder About Interfaces And The User Experience
Let's face it, we're programmers - we think about code - wonderful, beautiful, well-tabbed code. The biggest problem that we face is in our applications is that our target users are not programmers and they don't think about code at all. The only thing that they think about is what they can see and feel, which is of course, the user experience. Even when you are using something as powerful as Interface Driven Architecture, it is not always possible to really put yourself in the user's shoes; it's not always possible to experience the application in full-on "use" mode. And so, it is hard sometimes to predict where small interface tweaks will result in a huge gain in usability.
Yesterday morning, I wrote about a small interface tweak that I made to Dig Deep Fitness, my iPhone fitness application. The update was very small - I was able to default to the numeric keyboard when entering exercise weight and rep data. Once I figured out how to do this, the update to the software took all of two minutes (include the FTP time). Like I said, a microscopic change.
Yesterday afternoon, I took my iPhone to the gym and tried tracking my workout with the updated interface. After just the first set of the first exercise, I already felt a huge gain in usability in the application. While the interface update merely removed one single click from the workflow, it felt like so much more. Suddenly, the interface felt tailored to my application - it felt as if it were built for my use-case. With the removal of just that one click, I bet it decreased my data entry time by at least a third. I know that sounds crazy, but it's true. Or at least, it is perceived by me to be true; and, really, from the user experience standpoint, that which is perceived to be true IS true.
So, nothing revolutionary here, just a reminder to be always always always be thinking about the user experience and that changes that seem small and insignificant to you as a developer might seem huge and revolutionary to the user.
Reader Comments
I wish more developers experienced similar experiences to the one you describe. Most applications can expect a similar productivity increase after a single pass a user testing and making the changes required by the testing.
Also, for all the developers out there, it isn't really expected that you do all the user experience design work. Thats what interaction designers are for.
@Rob,
For so long, I only ever thought about what would make my job as a developer easier. I wanted to steer away from dynamic stuff because that took me out of my "list / view / edit / delete" comfort zone. The problem is, the less dynamic the interface, the less usable it probably is. But, I didn't think about the user - I only thought about my ability to code the interface. I was always concentrating on "implementation", not on "experience."
When I learned about Interface Driven Architecture, it was a HUGE eye opener. Thinking about the user interface with almost no thoughts as to implementation (other than the occasional sanity check) is amazing. It really frees you think about the user and the user experience without even caring about how things can / will be developed. I quite literally cannot imagine ever working on a project again that doesn't use this methodology.
Years ago, when I first started serious development, I was a solo outfit, freelancing Access VBA projects and CF projects. I learned very early on that I didn't necessarily have to make pretty software, but I *had* absolutely *had* to make software that the user actually wanted to use. In rare situations, a manager might insist on software his users didn't want, but only when that manager was already preparing to shake things up a bit. In most cases, after discussing projects and timing and costs with management, it was directly on to several hours with the user, because solving the day-to-day, hour-to-hour pain was the only compelling reason to even consider replacing current processes (or even current software).
And then I found that the same applied to me once I started developing the solution: no matter how RIGHT I knew my cool little trick was, if it wasn't what the user wanted to use, then it would not get used and what would be the point of that??
Sadly, as has been noted in the comments here already, not all developers learn that early in their careers. It can make all the difference in the world to definitively meet the user's need as closely as possible.
User Experience...hmm, sounds interesting.
Did I ever send you the samples of the book I can't find time to write?
Links here: http://commadot.com/the-book/
One trick though:
Never try to pretend you are the user. Pretend you are the application. Then imagine the user using you. Sometimes they press the wrong buttons. Sometimes you know what they want even though they haven't finished telling you. Imagine you are impatient and want to do your thing quicker, but the user is slow. What can you do as an application to make the process faster? Suggest answers or next steps to the user? Restrict confusing input? Make information come up faster?
It's much easier to design an application from that point of view. Users are not homongenous. 10 users, given the same task, will do it ten different ways. I address that in the sample chapters. Tell me what you think of it.
@Glen,
"Pretend you are the application .... Imagine you are impatient and want to do your thing quicker, but the user is slow."
I really like that. I have never thought of it that way, but I think that makes a lot of sense.
One of the things that I thought of when I read that was the CFFlush tag. I think when I want to use the CFFlush tag I am in that kind of a mind set. Sure, flushing the header content before the body content maybe only makes a split second difference in rendering, its my mentality to ship the info as fast as I can.
For anyone that maintains any user-oriented application, something I thoroughly recommend is simply sitting and watching users doing their daily tasks - especially new users.
Be sure to have a notepad and pen, and write down everything that makes them frustrated, causes them to pause, and so on.
(And of course, you need to follow this up with formalising the notes, providing them with a copy of intended changes, actually implementing, and so on.)
IDA is definitely powerful, Ben. I can't quite understand why so many programmers still treat user interfaces as secondary in importance. I've said for years that if my life depended on a successful software deployment (as defined by the users of the system), and I could manage only one aspect of the process, it would be the user interface.
It turns out, though, that something more important than my life is at stake: my career! Great post.
@Hal,
It's funny, as I was reading your comment, I started thinking about the reasons people push back against the idea of a full prototype. I would love to say that doing this decreases the overall time of the project development life cycle because there are less iterations of code.... but then, after thinking for another minute, I realized that that was a silly thought. Not due to the truthfulness of the statement (which may or may not be true), but because when you really think about the end goal, the time it takes to develop isn't really the biggest concern.
The *real* concern is, will this software be successful - will it be adopted and used and have a long life. This goal has very little to do with how long it took to develop (give or take), but this goal is highly linked to how well thought out the application is in the context of user needs. And THAT is why interface driven architecture is so important.
For people who scoff at the up-front cost of developing a prototype, think about it like this - it's like saying to your doctor, "We don't have time for a diagnosis! Just give me some medicine". Good luck with that :)