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

For the longest time the gadget market, be it laptops, mobile phones, PDA’s, digital watches or what have you, were dominated by black and gray things. They included an uncountable number of features and truth be told weren’t much for the eye. Some might say quite masculine.

Then market research showed that the majority of gadgets were being bought by women, and they tended to influence what was being bought for the home as well. What was more, they tended to focus on practical, functional and simple to use.

Producers of high-tech gadgetry having discovered that they had been ignoring around half of their buyer base came up with the great and simple solution: Just spray it pink. Shortly afterwards they decided that they needed to address this market segment especially and came up with calorie counters and period reminders. Thankfully this phase has passed and you can now find both tasteful, practical gadgets that are not overloaded with useless features.

Girls, for the latest in gadgetry, you should follow what’s happening here:
http://shinyshiny.tv/
http://www.chipchick.com/
http://www.gadgetmiss.com/
http://www.gadget4girls.com/
http://www.slashgear.com/tags/girl-gadgets/
http://coolgirlgadgets.com/

MD

When designing user interfaces it can be tricky to understand what the user needs on a certain screenful. The solution is not to just show him everything, that confuses the user and makes him less likely to succeed. Here it is good to adhere to the Goldilocks principle.

SingStar is a game where people compete in who can keep a tune better. Every shower-singer can show off their talent for his (and others?) amusement. But as every shower-singer knows, what he is hammering on in the shower is usually just the chorus. In between choruses we quickly get lost. The lyrics + supporting music can help a little but usually this is not enough (just visit any karaoke bar). So how do you show the user what to do?

Visualising music has been solved centuries ago and professional musicians are very good at reading score and interpreting it (almost instantaneously) into music. However, reading score needs years of training so it is not appropriate for a casual game.

The designers of SingStar realized that the only thing the users need are the length of each tone and information on whether the tone is up or down from where they are. The players have often heard the songs before and their memory and feel for the song can guide them to the right tone (or there abouts) when they know roughly where they are going. No need for training, just start playing.

That’s an excellent example of the Goldilocks principle in action.

MD

As I threw myself on the sofa, completely exhausted, I exclaimed: “How come we in software engineering can’t seem to manage creating complex things in the same way as you in civil engineering. I, mean, you’re so lucky, when you start out you have everything planned and specified in your blue prints. We’re always fumbling with changing requirements and customer needs while you can focus on the implementation.”

And he looked at me the way big brothers look at their little sisters, and said: “Little sis. We don’t know everything before we start. We consider ourselves lucky if we know 80%.”

This took my by surprise: “How can you build something that you don’t know in detail what is? You can’t change things that are set in concrete!”

But he continued to explain that they did their foundation work in detail and then as the building was built they filled in the details as they went along. “And that’s why,” he explained, “you always have the architect and lead engineer on site so that they can address issues as they come up and decide how to handle them.”

Sound familiar? Who are the architect and lead engineer in your project? Get them on board!

MD

UI design and programming is like throwing a dinner party and the programmer and designer take on the role of a host.

Think of a dinner party you have gone to. Some people, some food. These are the basic requirements for a dinner party. Without these elements there is no dinner and no party.

Throwing a dinner party usually involves other tasks as well. Tidying up, laying the table, making dinner, putting on music, lighting some candles. However, chinese food out of the carton fulfills the same basic requirements.

Not seeing the difference between these two means you cannot make user interfaces.

The software developer that can look up from the code and look at the interface in front of him and spot that the table isn’t beautifully laid, that there is no music, she is a host. He has a sense that when the users open the interface it is a reflection of him. And she wants it to reflect well on her.

It’s not a question of an eye for detail – sometimes it’s the big picture that needs to be improved. It’s not a question of understanding the requirements – these things are often not documented in requirements but inferred from the design. It’s a question of playing host and wanting the guests to feel welcome.

MD

We wanted to do a workshop that would give clinicians and developers practical tools in communicating that would lead to better functioning clinical software. That they would, for the first part, realise that they have a very different standpoint (you might say that they speak different languages) and, for the second, that despite of that they could easily work together. We covered basic software development concepts and user centered design. The team defined a basic clinical tool and designed a user interface for it. We even managed to squeeze in a little usability test.

As always when I teach, I learned a lot. We managed to get a good discussion going and teamwork flowing so we were quite happy. Teams were comprised of clinicians and developers alike.

Discussing requirements definitions, an attendee asked how much documentation is needed. This is a question that always pops up when requirements are discussed. Some people say documenting requirements is a waste of time and others say that documenting requirements is a vital part in the development process (even to be used as parts of contracts between vendors and clients).

I say that it depends a lot on the team. Documentation is fundamentally a way to communicate. When a team – especially a team made up of people from very different background – starts working together there is certainly a need to document more rather than less. When the team has worked together long enough for the whole team to share a vocabulary and understanding of the system that is being built, this need is grately reduced.

“Oh”, one of our workshop members exclaimed, “you mean like in a marriage.”

I like that. A well functioning team is very much like a marriage*. We finish each others sentences. We trust each others. We know each others strengths and weaknesses and compensate.

It’s getting to that point which is difficult. And in my mind the first step of getting there is for everybody in the team to realise that they may have different knowledge than other team members, that they may have different vocabularies and that they can learn from each other. Being different is a strength for the team. Respect that and learn.

So communication in the first iteration of development with a new team is crucial. It builds trust, it defines how the team will work together in the long run. Over-communicate rather than under-communicate. And then fine tune the level of communication needed.

MD

*Not that I’m advocating polygamy…

Starting out is very smooth for a Gmail account owner. I synced all my contacts from my iPhone to Address book. Exported them to VCard and imported into my Gmail account. As soon as I had set up my Gmail account I had all my contacts. Sweet!

One thing that I’ve learned that I want to share is there seems to be an issue with the Gmail account when the phone loses all battery power.

As recommended I drained the batteries 2-3 times when I first got the phone and first when I did this I noticed that my Gmail stopped syncing. The only solution I found online was to do a factory reset. I’m willing to do one factory reset but when this happened again after the second drain I played around until I found an alternative solution.

When this happens: Go to Market and open it. It will prompt you for your Gmail account password.

Then Gmail can sync again. I’m assuming that the password somehow gets lost when the power is lost.

It is a crying shame that Samsung doesn’t provide software for mac-users to update their phones with, load music and backup photos. I do hope that this is something they will rectify soon!

MD