Everyone has eyes, so we all know what good design is, right? I don't believe that is true. If that were true, we'd all be musicians if we can hear; we'd all be chefs because we can taste; we'd all be athletes if we had working legs. I think everyone has an instinct as to what is usable and what "works" for a design, but again, UX professionals have the experience of past projects and a few other factors:

• Just because you are a user, doesn't mean you think like a user (UX professionals have trained themselves to think like users)
• It's hard to manage priorities when you own the project and are responsible for representing the interest of 2 groups equally
• It's hard to own something and be objective about it

 

Just because you are a user, doesn't mean you think like a user

One of the challenges UX Professionals face on a daily basis, I think, is putting themselves into other people's shoes and trying to understand how the various groups will respond when they see what's on the screen. It's so easy to think how you would like to use a tool and what would be great features for you. However, at the end of the day, when you work as a product designer, you are not designing for yourself – you are designing for people who do not think like you.

User Experience types end up knowing quite a bit about psychology from running and attending testing sessions. These types of activities provide training so that UX Professionals can more easily think more about who is using the software and how those users will respond to the position of a feature or the color of a button (for exa,ple). This is a learned skill that happens over years of experience and practice. UX professionals also understand that if a feature is in question to keep or modify, they need to bring it to the users for testing. Sometimes a business owner will make a decision not to test based on their own experience and make a UX call. Sometimes this works; often this is a really bad decision because they are thinking as an advanced user – not as a general user.

The business owner is an advanced user of the product. They work with it every day. They were and are involved in creating the features. They have an intimate knowledge of how the product works. Most users of a product, well, they don't use it every day. They have surface knowledge of what the product does. Most users don't read instructions and want the product to be intuitive. If you use a product every day, you make a lot of assumptions for how it works. This is where testing is key to determine how users think, what motivates them, and what's intuitive for them. Users may be similar, but when it comes to familiarity with an application, that is an entirely different user group.

 

It's hard to manage priorities when you own the project and are responsible for representing the interest of 2 groups

UX Professionals represent the interests of the users. It's hard to represent the interest of the business and create a usable product when you are torn with thinking about timeline, budget, and what the business will get out of the final product. Sometimes, the needs of the users become secondary to making sure a product has all the features included that the business feels it needs for a successful launch. However, what a business REALLY needs for a successful product launch is a product that is universally accepted in the marketplace meaning that it is intuitive and useful. This is often pushed aside to have a feature go live.

I often will back away from a business decision to add a new feature or do some technical upgrade. From my perspective, these system needs have valid usability interests. The users are not going to use a product that has a slow load or response time, use incorrect or problematic data, or just doesn't work as expected. However, it is my role to present to the business what I see as needed for the user as well.

If a UX person owns the product, there is a risk that although the product will look great and function well, it may not always bring in revenue as expected or have some serious technical failings. If an engineer owns the product, sure it will work great and have phenomenal architecture, but will people figure out how to use it and want to use it? At the end of the day, the business really needs to own the final decision and judge what makes most sense to do from all angles – for revenue, for technology, for user experience. There really needs to be an objective product owner who has a vested interest in seeing a product get shipped that is successful – with a team definition of what "successful" means.

If a business owner isn't objective, it is very easy for the needs of the user to take a backseat to what's easy and cheap to implement – we can always develop to the "ideal" later (especially with Agile). Honestly, the success of your product depends on the user experience. You can't let that go or be compromised for cheaper implementations that users will find inferior.

It's hard to own something and be objective about it

Even if you have an ugly child, you always think your child is beautiful because it is yours. Your boyfriend/girlfriend or husband/wife is always attractive because that person is associated with you. The same is true with a product – if you have worked on it for many years, it's the best product around. Sure, you know its faults, but what you developed is awesome.

This is human nature and you can't go around it. Even designers and UX professionals do the same thing. After a while, a product owner will believe that he knows who is audience is – whether there has been focus groups or testing or not. It's just how ownership works. 

And UX Professionals love their users – and they are an extension of themselves sometimes. In a way this is a good thing – people take ownership of the product or the user experience and go with it. The best part about it – UX Professionals want to always learn more about the users which means research and testing.

Sometimes a product manager can get a little – well – too involved in their own products. They forget to do research and are too familiar with the product. They start to take criticism of the product personally. Again, this is natural. Most consulting firms will move consultants from project to project every 6 months for this reason – it keeps things objective.

Usability is objective – either people can intuitively use a product or not. It's fairly objective – after 5 people review a product and if they can't figure it out – well – go back to the drawing board. Sometimes product managers won't want to have usability testing, believing that they know better. Well, no one knows the user better than the users themselves. Again, this all comes down to objectivity. It's not personal – except for the users.

For these reasons and a few others business owners should not double as UX experts. I believe that all points of view in a project need to be evenly weighed and considered and you can't do that if you are too focused on the technology, the budget, the UI. You need to be focused on what is shippable product. Then you get the best user experience.

 

One of the things I've been hearing a lot recently is how having a UX person a team is expensive and if you can't afford one, it's not necessary anyway. It reminds me of a way of thinking – if you can taste, you can cook (not true – can disprove that with at least 2-3 people I know) and if you can hear, you can sing (I can disprove that in 2 seconds or less). If you can see, that does not mean you can design, work with users, understand their needs, or translate that into functionality.

I think this latest "problem" comes down to 2 issues:

• People don't always understand what UX people do (heck, some days I don't even understand what I do and for me to explain my job can take up to 5 minutes. Sometimes, people do regret asking me 🙂 ).
• UX involvement is perceived to be expensive

So what do UX people do?

User experience includes the copy, the design, the functionality – the general experience. It's what the user sees and deals with when he goes to a site, a store, uses an application, or goes through a workflow. User experience professionals may specialize in a particular area (or multiple areas), but in general, they always keep in mind the needs of the user.

To be a purist, this means that UX people get their information from research and testing. And yes, they always should do the research and the testing to make sure what they are building meets those needs. However, we don't always have the luxury in projects to work for 2-3 months to research the audience. And sometimes, even to do the work after a project is complete to create a library available for the next UX person, there is no budget available and no seen "need." So, you have to wonder, what does a UX person provide?

UX professionals have compiled knowledge over the years of working on other projects, and often this knowledge is transferable. They know what worked and what didn't. I think we all need to let go of industry specific usage – users are users and there are some similar ways of thinking. Just because someone is in banking doesn't mean he submits an expense report differently than someone in retail. The way we buy shoes is similar to how we look for a restaurant – we just use different criteria to get to the same thing. It's all about being able to identify a thought process and psychology and leverage that in a design.

So what is a design? Even designers today are being called upon to change their roles slightly. Lately, we're being seen as solution providers, problem solvers, and facilitators (no longer genius artists). In a way, that's a healthy view – design isn't art. Design provides a solution to a problem.

And in the world of Agile, design is a collaborative process. The developers have a say as much as the business owners and the UX professional and we are all solving the same problem, bringing to the table a different perspective and representing a different interest. Almost like the UN, but for software.

So, back to my original question, what does a UX professional do these days?

These days, I know I see my role as being the representative for the users. If the team needs the UI to look better, I help out where I can and get designers and copywriters to help. If we are adding a feature and we're not sure how a design will be accepted, it's my job to suggest usability testing and the cost. If we are in a meeting and I hear about a feature being implemented in a weird way, it's my job to speak up for the users and say "Hey, I think that is a bad idea. Let's try this instead."

With that said, I think someone representing the users and facilitating their requirements being implemented into the product is a pretty key role to have on a team. In fact, it's vital (and I'm not saying that to justify my job) from the perspective of a project team being like the UN (where if there is a conference on a third world problem, third world representatives are present). It's the Agile way, really. Otherwise, the business interests are represented, the developer interests are represented, the QA interests are represented, but what about the people who use the product? We can't depend on the business to represent them and prioritize their own needs (more on this in another post). There needs to be checks and balances.

To the second point – is it expensive to have this role on a team?

No.

In the world of Agile, IAs/IDs are no longer writing enough documentation to wallpaper a McMansion (they write documentation, yes – just not that much). Instead, they are being asked to leverage their knowledge and other resources to create an experience people will use. That means there are a lot of random instant messages, emails, page reviews, discussions – that spends maybe a total of 2 hours per day (no more than 10 hours per week for a project unless there is a sea of developers involved – then 1 person should be dedicated).

And to be the voice of the user in product development, the UX person will need to help get testing going. Now there are a lot of new technologies out there to make testing cheaper and virtual. There's no real need for the fancy, one-way mirrored rooms or the 10K tests with 15 users. Actually, you are almost better off to test with smaller groups more frequently (testing iterations) – which helps in the long term, allowing changes to the experience to be tested and a proven solution. This way UI enhancements can be prioritized to allow for shippable product at any time in the process (and more on this in a future posting).

I guess my point here, to the original question, is yes, we do need UX people on the team. Do we need dedicated people? No. Do we need to have the user's needs represented? Most definitely.

I previously worked on a blog for branding and user experience and how that all works together. I'm still going to continue with the blog (and try to be more consistent with the entries) and do the same with this one.

Over the past few years, I've been doing a lot of work with Agile and as a UX professional, have tried to integrate into an Agile team. There are a number of ways to work with developers and business owners in an Agile team, depending on the team, the communication style, how the team works, etc. I think one of the big changes for user experience professionals in the Agile world is simply – what is my role now? I know I go through this quite a bit.

There is some ambiguity about what a UX person does – especially because of all of the areas that can be addressed in UX. For example, I'm not a copywriter, but I know good copy when I see it. I can draft something for a writer to edit, but what I draft is often edited for style to be consistent with the rest of the site. I'm not a visual designer but I know a good, working design when I see it. I only design in 2 colors ([put color name here] and black/white), but I can give feedback as to what is functional. I don't really code or do testing (I sometimes do testing, but that's another story). So what do I do? And why are specialists needed?

From my perspective, I provide insights into what the users want and what their experience with what is being built should be. I help define that experience with the business needs and user's needs in mind and then work with the development team to make sure that we can meet those needs with an easily maintainable codebase that's not expensive to create. With Agile, I'm not required to overdocument and, in fact, like that I don't need to do that anymore. I'd rather talk to the developers and find out what makes most sense and record that conversation for later. I'd rather be on call to work with developers, let them think about what makes sense and give them feedback on what works and what doesn't work.

Lately I've been realizing that I'm not needed a whole lot on a project, but when I'm needed, I'm needed right now. I'll discuss this in future blog entries.

I think for the first entry, I want to cover the need for UX people on a team and in the one after that, what do UX people do.

Hope you enjoy the reading!