Such a developer gets it. Understands what I’m doing. Sees the value in it and respects it. I have worked with many developers that just don’t get it and a few that actually do. And they make me better at what I do.

There are varying reasons for developers not getting it. Here are a few that come to mind that I’ll discuss in turn:

• They don’t understand
• They don’t want people meddling in their work
• They don’t care

Some don’t understand UX and they truly don’t see that the changes that they make influence it. They’re not trying to be obtuse, they just don’t see it. You may show them the design and then their implementation side by side and they don’t see that there is a difference or even if the see it, they don’t see what difference it makes.

- Then it’s my job to make them see it. Make them see that you have a different perspective than they do, that you are thinking of a bigger picture, that you have input from other sources (users, theory, research etc.) and therefore you have made the design this way or that. Listen to him and discuss his points in this context.

Some just don’t like other people to have an opinion on their work or their part of the system.
- Then it’s my job to make them understand that working with me makes them perform better (and thus more glory for them).

Some actually don’t care (because they’re sloppy/burned out/spiteful/…).
- Then you have a bigger problem that truly needs the attention of the PM. Because if they doesn’t care about UX then my guess is that they don’t care at all. Then they’re showing other members of the team the same attitude (try asking the QA people). And that means they’re producing a substandard product.

Some of the best developers I have worked with have initially not gotten it. With time, with effort, with discussion, by earning respect they have. Of course it’s not a part of your job description and it can be infuriating at times because there is plenty of stuff that needs to get done but it’s the only way I know of that makes the product better.

I am not saying that my favorite developers implement my design without changing it. Of course they change it. Sometimes you don’t see that the design doesn’t work until it’s running. Sometimes you don’t see that you need to accommodate this type of data or that until it’s there. No design goes through implementation exactly like it was drawn out in wireframes or prototypes.

The difference is that the they don’t make a change unless they discuss it with me. Sometimes, when they’re completely on board with the design, they might make a change without consulting me first but it’s in line with the design so when they show it to me I agree. Then you can really take off as a team and produce wonderful stuff.

We more often discuss those that don’t get it than those that do. If you have a team member that makes you better at what you do, give him a pat on the back.

MD

- Inspired by a great discussion in the Interaction Design Association group on LinkedIn.

In your research, as you meet users and discuss the product with them, as you move through the organization and look at how the product is applied there, you stumble upon the big picture.

In many cases nobody else has this big picture because they are busy doing their job, not thinking about what everyone else is doing. Even management doesn’t understand the multifaceted picture and how it pertains to all parts of the company or external users. So you have a unique view of the product that the company is working on.

As we listen to our users we strive to fit the users’ needs into the big picture. We also need to make sure that the brand is maintained in the big picture. That there is a content strategy and information architecture that fits the big picture. And this means that you’ll be having a lot of conversations where you are the bad guy because you don’t want to do something or you want people to do something different so that it fits the big picture.

What you’ll soon realize is that the big picture spans other parts of the organization than the one you belong to. And that in itself creates a lot of issues. Your manager doesn’t like you working for other parts of the organization and managers elsewhere in the organization don’t like it when you want to have an opinion on what they are doing.

To really work on UX you need a strong backing from the whole organization to work because the product development touches on every part of the organization, from customer service to marketing, from development to operations. Therefore, when you have found the big picture, your most important stakeholders are above you in the organizational chart.

MD

It’s not about servicing the user by tailoring to their every whim. It is a about servicing the user in a way that makes them more successful while at the same time understanding that the user is not a technical person, not a user interface or interaction designer and many cases only has a limited view of how the product is used.

This is one of the most demanding tasks of User Centered Design. Because it requires from the designer to take a step back and understand what it is that the user means, not what he is saying. Understand what the users needs rather than what it is that they want.

This means discussing what the user wants to achieve rather than what bugs are currently annoying him or what he can’t do with the software he is using now.

An example might be a user complaining that the different systems he is using make it difficult for him to copy/paste dates between them because they use a different date-format. Here the knee-jerk reaction would be to make sure that all the systems he uses have the same date-format. Easy! But that is not the problem here. The real issue is why does the user need to copy/paste information between systems? Why are there so many systems?

It’s the ability to decipher the needs of the user from his wants that differentiates between a usability expert and a user experience designer.

MD

*”The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine” Abraham Lincoln

Yet decisions on buying software are being made, based on the only tangible thing available: Price (or in some cases the number of extra features).

What consistently amazes buyers of software is the difference in price for the “same thing” (meaning something that offers the same functionality). Now for us, producers of software, it is often clear as daylight that these are definitely not the same thing. But how to convey that to those not inclined to discuss the difference of RubyOnRails vs. java or the merits of hiring a web designer vs. their cousin’s kid?

Tell them the story of the three little pigs. Remember that story? Nobody tells it better than Christopher Walken:

The good thing about this story is that even if people have trouble understanding the technical terms of why some software is too cheap they understand the difference between the quality of the piggies houses.

Each piggy’s house was functionally the same. The piggies were quite content living there. The first two were much cheaper to build than the third, brick, one. We need to convince those with the check book that they should go for the brick one nonetheless. It pays when the big bad wolf comes to town.

MD

* They are incomplete, have usually not been collected from the users and are badly documented.

So to start out with I asked them to consider this (borrowing from my hero Kathy Sierra here):

The user is not using your software because he is fascinated by it. He is trying to achieve something. His success is dependent on him being able to maneuver through your interface.

Therefore our goal as software developers is that at any point in time the users know:

• where they are
• how they got there
• how they can proceed

The following tips help you achieve this goal.

1st tip: Don’t expect your users to read

When you find that you need to write an explanation about some part of your user interface you need to fix the interface. The explanation is a cop out to fixing the real issue and it doesn’t work

Any explanation that you write is not going to be read because when we move through an interface we’re skimming (not reading with focused attention). Which means that we only notice the things we are looking for and things that stand out (such as colorful large buttons that we are expecting to bring us to the next step).

Note: This applies also to help documentation.

2nd tip: Make a decision for your user

Making a decision is hard and it is really difficult to keep more than 3-4 options in mind at a time. If there are more options a lot of work is needed to narrow them down. Which means that we just don’t and move on (to your competitor!). If you have many options, present those that are most important to you (37signals do a great job here where there are 5 options but only 3 presented in focus).

This comes with responsibility. Some use this to trick the users. The thing is that unmaking a decision (made by the developer) is also a decision (made by the user). That’s why the newsletter is selected by default in many subscription forms. Use this with respect for the user.

This tip also applies to your product development. If you have everything configurable in your software it will become cluttered and complex. Select the defaults and feel free to dig the configuration down into the menu system. The thing is, most people don’t like to be able to configure everything. It just us, the nerdy types, that like that. Design the interface for the most common cases and hide the special cases. See also Lisa Reichelt’s post on Why most UX is shite.

3rd tip: Don’t make your user remember

Computers are just much better at remembering than people, we function on recognition. Which explains the importance of the GUI (in contrast to command line) in making computers household objects. If the user selected something in step 2, don’t make her recall it in step 4. Just display it.

4th tip: Users make mistakes

It doesn’t mean they are stupid or sloppy. It means they are not sure how this thing you have made works. Deal with it by allowing undo or at least enforcing a confirmation before execution. Allow people to get back to where they were before they stumbled off the straight and narrow.

5th tip. Listen but don’t obey

This is very important. Your users pay your paycheck so you need to listen to them. But note: They are not technical and they are not interface designers. They may not possess the overall level picture that you have from speaking with many users with different needs. Therefore it is your responsibility to find the best solution. Listen carefully, what they are saying, asking, pleading for you to fix may only be the symptom of what is actually wrong. Think about why this is important to them, what are they doing and what are they trying to achieve. (Thx for the improvement Már )

6th tip. People don’t like change

Remember the last big Facebook change and how people reacted? Now think if you would show up at work and somebody had completely rearranged your workstation. Sprayed your desk pink. Added stickers with unicorns and butterflies on the edges of your monitor. Even if it is better you’re going to feel out of control and that’s unsettling.

When you’ve worked really hard on the next version of your software it is very frustrating to get beat up about it when you deliver it. But think about it from the point of view of the user. He has managed to build up skill which you have now all but annulled. He is very busy doing his work and now you’re slowing him down. Try to involve your users. Even just to give them a heads up of what is going to happen. A big overhaul of Amazon prompted them to allow users to see the new version a few weeks before it was launched. Maybe they have comments. Maybe not. But it will at least make them feel less out of control.

I’m sure there are more tips useful for those getting started. Leave a comment if you have an idea for a tip or if you have a comment on any of those above.

MD

The talks I refer to were given in Icelandic. You can find the slides in the last two posts:
Hvernig losnar maður við heimska notendur og Að vinna ástir notenda

Samlokufundur Félags Tölvunarfræðinga, valentínusardaginn 14. febrúar 2012:

Hugbúnaðarráðstefna SKÝ 11. janúar 2012:

MD

This is a good thing. We who have a psych background have been waiting for the software development community to pick up on well known psychological principles that they can use to better understand their users and make user friendlier software. But… (here’s that but again).

In many cases when people discuss for example gamification they mention tips and tricks that can be used to lead the user in some behavior. But since they are talking about gamification but not the psychological principles that are in play, i.e. behavioral modification they are really handing out tools to the audience without the manual (how is a topic for another post).

Being ever the optimist I still like the fact that we’re finally starting to talk psych in software development conferences. If we can change the way software product managers, designers, developers think of the user, that’s a huge step in the right direction. The attitude that you all to often hear is:

The user is stupid

This idea frees the makers of software from doing anything to improve their products. It’s the user that needs fixin’ not the product. If we get the software community (to begin with) to shift their attitude to:

The user is a pigeon

as gamification suggests

then at least we have opened their minds up to the fact that there is something that they can do in order to help the users in using the product. This is a huge shift.

The important part is that we continue talking about psychology and human behavior at software conferences. That we enhance the understanding of users but not deliver what psychology has discovered about people in sound bites. We need the software development community to understand the basic psychology behind these principles so that they can apply them to their production and improve on user experience and the success of software users everywhere.

MD

This blog post is inspired by a great chat with Kathy Sierra, Sarah Milstein and Tony Stubblebine

Many of you (the ca 50% who are male) don’t have a strong opinion on the experience of buying underwear so let me explain.

Buying underwear is an unpleasant experience. You’re naked in a foreign place being measured against a popularized body image impossible to fulfill. It’s awkward, it’s uncomfortable and it can be downright humiliating.

I remember stepping into an underwear shop back home. I picked out an item that seemed to fit the criteria and was pointed to a fitting booth. The humiliation began forthwith.

The booth was very small. I kept on bumping against the sides. This made me feel like a beached whale. I kept hearing the person next to me struggle as well. The booth only had a curtain. The booth was cold. I stripped down to topless and felt exposed. The booth was lighted with strong white light which made all the flaws in my skin appear. I was pale, had shadows under my eyes, scars from acne, operations and other marking events stood out. All in all it made me feel overweight, sickly and vulnerable: Unattractive.

This is what Victoria’s Secret have perfected. The booths are warm, spacious and private. There lighting is soft and I’ll bet that the mirrors are tainted. I wouldn’t be surprised if they were slightly concave. There is a person dedicated to assisting you in finding the right model and size. When you’re trying on the merchandise you feel like a dame. Even in my very pregnant state I felt attractive.

And Victoria’s Secret was well compensated for their effort.

MD

Poll: As a designer, would you want your developers to tell you if they think your designs are outdated? Or keep quiet and let you fail?

Reference

It got me thinking about my projects and how much better results I get when I’m working with a web developer that I trust, that gives me feedback and is committed like I am to creating a great user experience with the product we are creating. I have been fortunate enough to work with a couple of developers like that.

So I replied to Drew:

@drewm The dialog between the designer and the developer makes the end result much better so I want to discuss

Reference

and i decided to see what other people are thinking and ran into this reply:

@drewm as a developer: would you like your designer to tell you they think your code is inefficient and bad structured?

Reference

A few other repliers shared the same sentiment. And I could see that Drew like me thought about roles cause his next tweet was this:

It’s a balancing act between wanting the project to be the best it can be, and overstepping the mark with someone else’s role in the team.

Reference

Of course in any team roles are important but sometimes team members lose focus on the end result and start focusing on roles. And that is detrimental to any project.

When all team members transcend their roles and prioritize the outcome of the project over their job description you get a better outcome. When team members are ambitious on behalf of the product they are creating over their careers you get a superior product.

So I’m a little worried about the responses that Drew got. They indicate an unwillingness to discuss, to cooperate, to work together for the best result. The indicate a willingness to fail, to assign blame. Makes me wonder what sort of welcome feedback from testers receives in these teams. A little later Drew posted the result of the poll:

Poll results: most designers would want to know, but wouldn’t want to be told. So, osmosis it is, then.

Reference

I of course didn’t see all the responses that Drew got so I don’t know how he came to this conclusion but regardless I think it is such an important thing to keep the dialog open that who we believe wants discussion and who doesn’t is beside the point. The dialog should be open. We can open it in all our teams. Let me start by saying:

Please, when you start implementing my design, tell me how it can be better so that we can create the best user experience for our users.

MD

The only constant in human computer interaction that you can count on is this: Humans make mistakes. Why it makes a lead headline is baffling. But it also typifies how people think about communication with complex devices. When something goes wrong it’s the human’s fault. Human error means that the system wasn’t at fault, it can be solved by flogging the human.

In many cases (I’m not maintaining it was the case here) this ‘human error’ can be traced back to flawed communication between the human and system the human is controlling. There are even those that maintain that there is no such thing as human error, only design error. When designing systems that are to be used by humans the designer has to include the human as a part of the design. And the human will make mistakes.

So plan for it, deal with it.

There are many ways you can help your users stay on the yellow brick road. You can make inappropriate options unavailable. You can have an undo function. You can ask the user to confirm his action before executing. You can make the flow of the task intuitive. Whatever you do it’s your responsibility as a designer.

This is not only important for us to realize as human computer interaction people. It is also important for the users themselves to know, and the organizations and legislators. Because we want to know when a human makes a mistake with our systems so that we can learn from it and stop making it happen.

MD