M-Pesa is a mobile-phone based money transfer service. Currently it’s mainly used in East Africa.

Here a short interview I did with a driver in Kenya about how he uses M-Pesa.

What do you use M-Pesa for?
I can send money to my wife, and I can pay bills.

Can you also use it to pay at stores?
Yes, you can, but I don’t do that. I mainly use it for transferring money. 

How does it work?
You need to have an account at Safaricom [the mobile network operator]. And you need to top-up some money on your account. The person which you want to transfer money to also needs to have an account.
When you want to transfer money, you send a SMS to Safaricom  with the phone number of the receiver and the amount you want to transfer. Then you enter your password.

How much does M-Pesa cost?
One money transfer costs 30 Kenyan Shilling [about $0.30] and money-withdrawal costs about 1% of the amount you want to withdraw.

How did you pay your electricity-bill before you had M-Pesa?
I had to go to the office of the electricity-company and wait in line to pay the bill with cash.

Conclusion

Even though the costs for transferring money are not low ($0.30 is a lot for a Kenyan since GDP per capita is about $1000), M-Pesa is a success, since it makes transferring money so much easier.
To me it was striking how easy it is to transfer money with this system. When you compare it to e-banking in Switzerland, which is a chore.

More information

Listen to another interview with a driver in this Video.

The first UX Book Club Switzerland in 2012 took place in the new office of Ginetta in Zürich. Usually about 6 people attend one meeting. This time, there were 18 people attending - a new record! A lot of new people joined the book club. Whether it was due of the new platform we used (Meetup.com) or due to pure coincidence is not clear.

We discussed the book “Mobile First” by Luke Wroblewski. Because we we were so many people, we split into 2 groups. I think this was a good idea, because discussion is easier when you are not too many people, but still we had enough diversity in each group. E.g. in my group there were Frontend Engineers, Art Directors and Usability Consultants. This diversity is very important, because it guarantees new perspectives, which you may didn’t get when you were reading the book.

Here some take-aways from the discussion:

• Some members told us about their experience with the method “Mobile First”. One experience was that it can still be hard for the customer to prioritize, even with “Mobile First”. But it can also happen that a customer suddenly wants to do a mobile site, even if it has not been planned in advance.
• The book could give more guidelines how to handle a “Mobile First” project. E.g. with an example-project.
• Want more best practices for mobile development? The iOS Human Interface Guidelines are a good starting point.
• The difference between Web Apps and Native Apps will blur more and more in the future. Functionality like camera-access will be accessible from websites and look and feel will become similar. Today, some web-apps have an iPhone-Style and other have an Android-Style. But Twitter and Facebook are good examples how style across mobile platforms and the web will be harmonized.

Does the concept of the UX Book Club sound cool to you? Join our next meeting. It’s fun!

After post #1 and #2 about the contact form by the Swiss credit card company Viseca, there is still room for a third post: The form contains a form field for entering your credit card account number.

The account number normally starts with “1107” so you are tempted to enter a “7” in the first field. But the first field is not editable, it’s read only. So possibly the customer is supposed to enter the rest of the number into the second text field.

Conclusion: I see no reason why there should be two text fields here. It could be one text field and contain “110” but still editable. This would be much easier  to understand than the current solution. See an improved version in the image below:

My last blog post was about the yellow checkbox in this contact form by the Swiss credit card company Viseca, but wait: there’s more. The next hurdle in contacting them is a birthday form field. First of all I’m confused that they need my birthday date for a simple inquiry, but that’s another story.

1. On a Mac with Firefox the form-field is not long enough to show a full birthday date like 16.12.1966 (even though on Windows 7 the field has the correct length)

2. A date-picker does not make much sense for a birthday date (it even contains a very useful “Today” button).

Conclusion: It would be better to tell the user in what format the birthday date should be written. See here an improved version of the birthday field:

When I first saw this contact form by the Swiss credit card company Viseca, I thought “A yellow checkbox? What is that supposed to mean?” Then I figured out that this possibly means it is selected. A selected checkbox should look like a checkbox and not like a yellow box. This is a well-known convention across the web.

When there are good conventions, don’t be creative and invent a new fancy design that will irritate your customers.

Do you want to know how the story of this form continues? Check out my second blog post about this form.