Who is the User?

To me, user-centered design in software development is about building software that meets the needs of the user because it's built with their needs and desires considered from the start. Traditionally it was the business analyst interviewing stakeholders who came up with the requirements for a particular software product. These requirements were then handed over to developers who would take the requirements that were translated by the business analyst and create the final product. When this process was followed, more times than not, the delivered product did a poor job of meeting the users actual needs and desires. Why is this? Is it because the business analyst did a poor job of translating the stakeholder's conveyance of what the product should be? Perhaps it is because the developers didn't understand the requirements?

In reality, most of the time, it's not the fault of the business analyst, stakeholder or developer - it's more systemic than that. It's that no one actually made the effort to try to figure out what the end-user of the product actually wants or needs. Ultimately, no matter how well a software product is built, if it doesn't satisfy the user's needs and wants, it is going to be a mediocre success at best - and fall flat on its face at worst. This is why it is so important during the requirements gathering stages of a project to determine profiles for real users and keep them in mind for every step of the development process. This can be accomplished by determining user types and sub-types and creating personas based on these defined types.

User Types and Sub-Types

For many software products there will be obvious user types and sub-types. For instance, if you are building a health insurance website, there will be primary types of say "already insured" or "not insured" with sub-types of "healthy" or "health challenged". You might have a combination - already insured/healthy or perhaps not insured/not healthy. Determining these types are going to determine what products you show or offer these particular users. It's pretty safe to assume for an insurance website that the primary goal for all users is to obtain affordable health insurance coverage with the best possible features available. If you can use types and sub-types to classify your users, you already have a better understanding of what your users concerns, wants and needs are, as well as how to match up your product offerings to those users.

Awesome, this is a great first step! We are on our way to understanding our users and giving them the products that they are looking for. Of course, software development, especially in the age of the web, isn't just about offering the correct product. It's about understanding how our users are going to use the software so that we can optimize it to guide them to fulfill their need or want. This is where personas can help.

User Personas

User personas should be looked at as real people. They have names, they have pictures, they have lives. They go about their daily life and perhaps, if you are engaging enough and have a product that they are the least bit interested in, they will fit in some time to their days - or even ONE of their days - to sit down at a computer and fire up your website and give it a go. Understanding what is tolerable or maybe even enjoyable for them to use takes a much more granular look at the user as a person. After all, they are people! As developers it seems like we forget that our users are people sometimes. That their one goal in life is not to sit down and figure out how to use our software. The have jobs, they have kids, they go to a Friday night card game and watch football on the weekends. They really like to eat tacos and yes, they work the 3rd shift at a manufacturing plant. When you look at users as real people, you start to think differently. You start to think how your product REALLY fits into their life.

Now that you have developed some user types and sub-types, it will be easy to create a handful of personas to use throughout a project. A simple template for a persona might include:

• Person's First and Last Name (make one up)
• Person's Type and Sub-Type classification
• The person's age
• The person's sex
• A photo representation of the person (to make them even more real)
• A bunch of personal information about that persons likes, dislikes, lifestyle, job, etc. These don't have to be any specific list, but it should be real. It should vary from persona to persona. You don't necessarily need to list every persona's favorite food, but some might. You get the idea, it's somewhat free-form and organic.

It shouldn't be a super-long description, but it should be enough so that when you read through the persona, you have a feeling for what that person is like. Perhaps you'll be able to compare them to someone that you personally know, perhaps not. But they will feel real. The persona's life will be a consideration in everything you do because ultimately, they're the user. They're the ones that need to adopt and use the software you are building.

Conclusion

There's really not much else to say about it. Creating some solid user types and sub-types combined with persona's are only one step in the user centered design process - but it's a huge step to understanding who your users are and how they might use your software. As I mentioned before, successfully meeting a users needs and wants is ultimately what is going to drive the success or failure of your software.