Monday, September 15, 2008

Personas in Software Development

Personas are a very valuable tool in the software development process. Personas allow you to humanize your customer, giving you a more "personal" relationship with them. By humanizing the customer, you are more easily able to empathize. It isn't until we are empathizing with our users that we can start the process of building great software.

The most common way to create personas is to distill the market information from your existing customer/user pool. If you provide project management software, it is likely that you have a group of fairly similar project managers and a group of fairly similar task assignees. By looking at these two groups, you may find a few very similar groups: highly-technical PMs, non-technical PMs, occasional-use assignees, and frequent-use assignees, for instance. You now have the basis for creating four personas that will help you understand their needs and then guide your product to meet those needs.

Not every product has an existing set of customers/users, however. This is most often the case when building a brand new product. In my opinion, this is perhaps when personas become most useful. (Bad metaphor alert!) Building a new product is like creating a piece of art (Ouch, that was painful!) The comparison, however, is valid. Just as in creating art, you have infinite options (just start by thinking what are you creating: painting, drawing, sculpture, etc, then deal with subject...), so to do you have boundless options in a product.

With a wide-open canvas, personas give you a way to make decisions and understand compromises. By knowing who I'm building for, I understand whether I need to spend more time simplifying my interface (for the novice) or providing more customization (for the expert). I also have a criteria to judge whether a feature is going to be successful by understanding motivations that would cause people to use...or abandon...the product.

So a new product means that, in some ways, I'm making up my personas. My personas are my target market, which I know very little about. However, if we don't understand our target customers, there is no point in building the personas. Somewhat of a Catch 22.

We often ask the customer "how do you do X?" because we think "X" is pretty cool and would make a good feature. Stepping back, we need to understand why somebody would being doing "X" in the first place. What are our target customers' reasons for using our product in the first place: what is motivating them?

Motivation is the most useful piece of the persona. If we don't understand our customer's motivation, the persona will not help us build better software. Instead, one of two things will happen: we will either be led astray by building features to fulfill needs that don't exist or we will recognize the tool as useless and put it in the back of the toolbox.

Building out personas in this case is an iterative process. Start with the information you know: what group are you targeting your product at. Make some best guesses as to what is motivating them, then validate those guesses with actual potential customers. Circle back around. As with any iterative process, don't get stuck in an infinite loop! Be pragmatic and realize when you are approaching equilibrium.

There is a lot of information that can be put into personas. Taken to one extreme, you can follow the toolkit on George Olsen's blog. It is a fairly comprehensive toolkit that will give you a very detailed persona. Regardless of whether you decide to use all the information, it is worth reading to understand things you could think about.

The other extreme is some basic biographic and demographic information. Without enough information, you won't have the detail you need to either empathize with the persona or, worse yet, to understand the motivations.

Here is a basic template of the information I use. Take it for what it is worth. The idea is to get enough information to make logical decisions without being overloaded with too much information.

Basic Information
  • Name:

  • Description:

  • Photo:

  • Age:

  • Sex:

  • Occupation:

  • Location:

  • Marital Status:

  • Children:

  • Income:

  • Education:

  • Computer:

  • Cell Phone:

  • PDA:

  • Other:

  • Primary Device:

  • Web:

  • Phone:

  • Applications:

Information Usage
  • Information Used:

  • Web Sites:

  • Applications:

  • Paper Usage:

  • Access/Day:

  • Locations/Day:

  • % Mobile:

  • Mobile Type:

  • Primary Connection Speed:

  • Mobile Connection Speed:

  • Social Network Role: [Connector/Spanner/Broker/Specialist]

  • Acceptance of Innovation:

  • Technology Attitudes:

  • Technology Religions:

  • Technical Proficiencies:

  • Hobbies:

Goals and Needs
  • Usage Goals:

  • Emotional Goals:

  • Motivations:

  • Needs:

  • Frustrations:

  • Computer Proficiency: [Novice, Advanced Beginner, Intermediate, Expert]

  • Web Proficiency:

  • [Application] Proficiency: [fill in appropriate applications (e.g.]

  • Social Network Proficiency:

Persona Details
  • Persona Type: [Focal/Secondary/Unimportant/Affected/Exclusionary/Stakeholders]

  • Business Relationship:

  • Persona Relationships:

Profile Narrative
Here is a few paragraphs of relevant background information about the persona

Most of the applications I've been involved with in the design process are web application, so this tends to be skewed that direction. The Technographics and Information Usage sections may vary depending on the type of application you are building. Fill in with data appropriate for your needs, but remember to validate it!

Finally, there are a lot of bullet items there. People like stories; it is easier to relate to stories than databases. If you can put the relevant information into the narrative, do it! It makes it more human. Just make sure you do capture all of the information you need for your personas. If handheld device type is critical, put it in both places: make it easy to relate to and easy to look up.

Building personas is not easy, but, really, the other option is to put some answers you think might be correct on the dart board...and throw a blindfold on while you are at it. You've got to know who you are building your product for!

Tuesday, September 2, 2008

Wireframes Using Balsamiq Mockups

I think one of the most difficult times during product development is during the initial user interface design, specifically the period between napkin chicken-scratches and high-fidelity mockups. It is during this period when you are typically deciding on application workflow and beginning to expose that workflow to people outside the product team.

The problem is that napkin chicken-scratches don't give enough of a sense of the real use of the application. Conversely, high-fidelity mockups don't provide people with enough imagination latitude to think about other possibilities. My solution in the past has been to use Photoshop to do line-drawings mockups like this:

Photoshop Wireframe

They are good in that they enable people to "fill in the blanks" with their imagination, which we can capture with further iterations. The problem is, though, that they are still tedious and time consuming to edit. For a long time, I've wanted a tool that gave me the ability to do these line-drawing mockups but much easier.

Not too long ago, I stumbled across Balsamiq Mockups and quickly fell in love. It offers the "use your imagination" lines of a whiteboard with the reusability and easy editing of a document. Take a look:

Balsamiq Wireframe

The current feature set is reasonble. It gives a good editing environment with a nice set of controls. It has really hit about 90% of what I need.

Perhaps more relevant is that, in the month I've been using it, that number has gone from 80% to 90%. The author is very good about developing and deploying new features. Balsamiq is a one-man micro-ISV, but the level of support he gives puts any other software shop I've worked with to shame. Peldi gets a big "ataboy" for that!

So, what's missing? Really, only two things:
  1. First is importable images. Images are all placeholder boxes, which aren't quite sufficient on visual applications. This feature is currently in development.

  2. Second is application workflow. While I can create mockups of the ten screens in my app, I can't show how or why a user transitions from one to the next. I currently have to do that out-of-band from the application, which slows my work. Balsamiq has also indicated that this will be addressed in a future version as well.

That's it. Sure, there may be some other controls that are missing, but every piece of software has that. Given the quick turn-around on many features, I don't think there is much to worry about there.

If you do much application UI brainstorming, definitely check out this tool!