Philoking.com

I remember back in the day, you used to get a huge manual with any software you bought. When I got C++ 7.0 (which shipped on 27 floppies by the way) it came with about 30lbs of manuals. Windows, Photoshop, Autocad…they all came with tomes to tell you how to use them.

These days nothing comes with a manual. When I purchased Logic Studio a few years ago I was shocked it came with a 10” stack of manuals. Heck, these days you are lucky to get a disc, now it’s just download and use a key much of the time.

Where’s My Damned Book?

I say that in gest. The point of this article is not to blast cheap software manufacturers who don’t give us paper anymore (they do usually put something resembling a manual online) but to applaud the rise of software development principles that are entering the golden age of software that doesn’t need manuals.

Keep in mind that in the early days computers were alien. Part of the manual was to take a person who was uncomfortable and unknowledgeable about these systems, and teach them how to do something useful with it.

Once Windows 95 had cemented the Window Managed operating system with it’s explosive growth, users had total command of clicking, double clicking, dragging, dropping, etc. No longer did technical writers have to assume that users had no idea what context menus were or how to use settings or preferences panes. Software engineers stopped being code monkeys and branched into teams that specialized in different parts of the process, and from this came the all mighty User Experience designer. There are about 30 different things they call themselves these days, but the main goal of the UX guy is to take the tasks that the user needs to accomplish with the software, and make them simply make sense.

Now that users had a solid grasp of the fundamentals, the whole way software was designed changed. Instead of designing the software in a way that made sense to computer nerds, we started asking questions like “What would the user expect?” and trying to make parallels to real world experiences so the software feels more natural.

Touch Me Baby

The iPhone took this to a whole new level. In many ways the iPhone has kind of reset how we look at software in general. I know in my professional career we are looking at everything through new eyes. All across the world, and much for the first time, software companies are thinking “what would we do if we just started over?”

Keeping up with legacy software and customers can be a real tax on innovation, and touch technology has given many software companies the first solid excuse to just wipe the slate clean and start over.

With touch input, software has taken yet another step forward in feeling natural. Software designers are having to think past common paradigms like double-click and drag and drop, to come up with new ways to accomplish tasks in ways that just make sense.

A Glimpse into the Future

Part of this scares me a little bit. As a self-proclaimed “Power User” I am somewhat unnerved by devices like the iPad, and I do have one. Right at this moment I am using Windows Live Writer, Windows Live Messenger, Zune, Internet Explorer, Tweet Deck, Windows Live Mail (Can you tell I work at Microsoft yet?) and Photoshop. I can see all of them right now. I don’t have to hide one of them to switch to another. If the iPhone and iPad can manage to murder double-click, drag & drop and context menus, can they kill Window Management? Will people get used to not having it and it just go away? I can’t imagine how that could ever do for people who really do work with computers, but for consumers, who knows? If so, is that a bad thing?

Right now I feel totally claustrophobic on an iPad, why can I only see one thing? Why can’t I USE more than one application at once. It’s not that unheard of. One big company takes a bet on removing a technology, and before long it’s just dead. Usually there is a forcing function behind the scenes like USB-Keys effectively killing CD/DVDRW, but sometimes technology gets made more accessible and the mass market is more appealing than the niche market so features just start to go away, reverse feature creep.

Where Am I Going With This?

Nowhere maybe, I am not sure. I love how our industry has evolved from an awkward relationship between user and machine to machines becoming a natural extension of users. I look around these days and marvel at the technology that is at my fingertips every waking moment of the day, and I am beyond excited about the future. In my experience the industry is cyclical. We have started down an app centric road, which lends itself incredibly well to the current task-based design principles. The idea of getting a user in and out of an experience quickly and painlessly is fundamentally sound. The problem is that not every problem can be distilled down to a 30 second start-to-finish experience. I write Business Intelligence software. Problems are complex and the software must always manage a certain amount of complexity. I don’t think that a business Analyst wants to be popping in and out of a dozen apps to do his or her job.

I guess that’s the part I am trying to solve in my head. In an app centric platform like iPad, the home button experience is jolting. You feel like you have just abandoned your work. I am sure after awhile that feeling will change, but there is an engineering problem there to solve I think. Let’s start the discussion there shall we. If you were building a new User Interface, to manage multiple running applications, and you couldn’t use Window Management, but you didn’t want to do the full screen only experience either, what would you expect? What natural experience could you relate to it?

Imagine if you are cooking Thanksgiving dinner. Each dish that you are working on is an app. The app is what helps you make the dish, but you are making a half dozen dishes at once. You have to manage some shared resources like your oven, stovetop or microwave. How do you manage these multiple tasks in real life? Unless you are Monk, you aren’t wiping the counters down, putting everything away and starting over with each dish. How would you extend the analogy to software? You need your apps running, you need to be able to see changes to apps in the background and react to events.

The alert system doesn’t manage this effectively. Apps need to be able to communicate with you and each other. Join the discussion in the comments, I am very curious for feedback.

Ok, maybe that doesn’t make a whole lot of sense, but work with me here. In the software development world, a lot of times we talk about who our customers are. Not what kind of pancakes they like, or what they think about rainbows, but what set of characteristics makes them a unique user type.

With almost any software, there are multiple ways it can be used. To help us decide how well a feature fits in a particular product, many times we will develop a persona of who our target user is and how we think they might use our product.

What Exactly Is a Persona?

The almighty Wikipedia says:

Personas are fictitious characters created to represent the different user types within a targeted demographic that might use a site or product. Personas are useful in considering the goals, desires and limitations of the users in order to help to guide decisions about a product, such as features, interactions, and visual design.

We deal with personas in my work life all the time, but as I deal with many amateur developers and web designers, I thought it might be valuable to share this technique and maybe get some feedback from readers that have their own unique perspective.

How Do You Build One

The obvious answer is first get to know your customers or users. Who are these people and what do they want and need to do? Watch people use your product. Learn the tendencies and habits of these people. A good place to start would be by reading The Inmates are Running the Asylum by Alan Cooper. This book will explain the great detail of some of the ideas I will share next.

The basic concept is this, you imagine. Of course you can back your imagination up with statistics, usability studies and all manner of scientific data, but they key to creating them and using them is imagination. You have to be able to imagine using your product through they eyes of someone else. Someone that might have more limited knowledge or capabilities. Sometimes you might have to imagine someone with much more capability. (for example designing an SDK) The key is being able to suspend what you know, or what you think you know, and imagine your products and ideas through the eyes of who will potentially buy, use and hopefully love your software.

The Benefit

In our work place, the obvious benefit is it allows everyone on the team to know who we are talking about as a user when we say “Bob would definitely want to do this.” We speak of personas as people all of the time where I work. We have all studied and understood who the character is, so we are able to communicate with each other as if the person was a real user. The benefit is that the fake person IS a real person, or better yet in our case, millions of real persons.

Personas are particularly useful at diffusing disagreements about product designs. When you have a group of intelligent, strong willed people, who all believe passionately about what they are working on, sometimes passion overrides logic. Even when someone is very loyal to their particular design idea, it’s easy to explain the negatives through the use of a persona, hopefully without offending the person in the process.

More Practice (Scenarios)

Once you have established strong personas, the next step is to write compelling user scenarios through the eyes of your personas, but that’s a blog for another day.

More Reading:

Persona Development

Scenario Development