A brief introduction to the QR code

The following blog post is adapted from a presentation I did internally at Capgemini Stavanger. The presentation was done as a 12 minute “lighting speech” to give the audience a brief introduction to QR-codes and what they can be used for.

All the mobile screen shots were made on my HTC Desire where i used “Barcode scanner” to scan the QR codes.

• Short for Quick Response
• A 2 dimensional bar code
• Unlike most 1D barcodes, the QR code stores information, not just an ID
• Designed for high speed decoding
• Created by Denso Wave for Toyota in 1994
• One of the most popular types of 2D bar codes
• Free of any license
• Defined and published as an ISO standard

QR codes are a great way to create better user experiences by creating a bridge between the physical with the virtual world.

What can they do for me?

Store text

QR codes can be used to store a simple, unformatted text message. Below is a sample of text messages and their corresponding QR tag.

• Short text
  
• Short text = small tag
  
• Longer text equals a more detailed tag.
  
• Longer text equals a more detailed tag.
  The longer the text, the more detailed the tag.
  
• Longer text equals a more detailed tag.
  The longer the text, the more detailed the tag.
  However, more detailed tags are also harder to read, so keep that in mind and don’t put too much text into your tags!
  

Notice that in the last tag with more text you also get more error checking and position indicators.

Scanning the last QR code will simply give you the text on your mobile with a few options:

Store URLs

The most frequently used feature of QR codes is to link to websites. Just like with text, longer URLs make more detailed QR codes that are more difficult to read.

• http://www.capgemini.com
  
• You can also link to applications. This links to QR Droid on Android market
  

Remember that if you use an URL shortening service, the actual URL remains hidden until the user clicks the link. Users are more likely to trust a link that they can verify as valid than a shortened link.

Scanning the Capgemini.com QR code will show you the URL and give you the option to open the website in your browser:

By selecting “Open browser” you open the page in your default browser (below).

Store phone numbers

A less frequently use of QR-codes is to store phone numbers. I can see that this can be useful if you have a long support phone number, but typing a phone number is usually not that much hassle.

• +47 912 34 567
  

Scanning this code lets you choose to dial the number or store it in your contact list.

Choose “Dial number” and you go to the pre-filled dialing screen (below).

Store e-mail addresses

A tag that stores an e-mail address lets you choose to either send an e-mail to the address, or add it to your contacts. The tag below contains my company e-mail in Capgemini.

• firstname.lastname@company.com
  

Scanning this tag gives you the option to write an e-mail to this address, or add it to your contact list.

If you choose to “Send email”, you get to choose your e-mail client, and it takes you directly into “new email”-mode with the “to”-field filled in.

Store SMS Messages (ready to send)

This feature may be useful for SMS-campaigns. It lets you pre-define an SMS with both the text and the phone number to send it to.

• Pre-written SMS message containing the word “SUBSCRIBE” sent to “+47 912 34 567″.
  

When the tag is scanned you get to choose if you would like to send it as SMS or MMS.

If you choose SMS, the SMS screen pops up with a completed SMS message ready to send.

Store geo locations

One of the more interesting features is the possibility to store geographic locations.

• The location of the Capgemini office in Stavanger.
  

Upon scanning the tag you can choose to show the location on a map, or get directions to the location from where you are.

The location for the Capgemini office. Notice that I included a search phrase because there are several companies located at the same address. This makes the result more accurate. Otherwise it would have said “Maskinveien 24, Best communication Øst and 11 others”. Not very helpful.

Store contact information

One of my favourite features is the QR-contact info tag. This encodes a vCard as a QR code with all of your contact information. Great to put on your business card. Saves people the hassle of typing your details into their phone and lets them know how tech savvy you are. ;p

• My business card in Capgemini (note that the phone number is fake. )
  

Scanning my QR business card brings up all the info in the card along with a few options for what to do with it.

If you choose to “Add contact”, the contact page pops up with all the information pre-filled. All you have to do is click “Save.

Store calendar events

Another great use, that I wish I had seen more of is encoding events as QR codes. You can store all the information you need about an upcoming party, conference, meeting, trip or gathering of any kind in the tag.

• Perfect to include in invitations.
  

The tag can store a title, start, end, location and a description.

When you click “Add to calendar” your calendar pops up with all the information about the event. Just add your reminders and click save.

Store wireless network information

This is another overlooked feature of QR-codes. You can connect to a wireless network by simply scanning a QR code. The code contains network name, password and encryption type.

• Below is a sample WiFi-tag
  

When the tag is scanned you can verify the information about the wireless network before you click “Connect to Network”.

The phone will take a few seconds to set up the network…

…and once you are connected you will be presented with your start page.

This would be great for hotels and event centers where you get a temporary WiFi-login (usually a ten character string of random numbers and letters for both the username and the password that take for ever to enter on your phone).

Sounds great! How do I make them?

There are several QR code generators on the web. Here is a list of the ones I have used:

• http://zxing.appspot.com/generator/
• http://delivr.com/qr-code-generator
• http://beqrious.com/generator

I primarily use zxing, but beqrious has a nice feature where you can add an image to the centre of an URL-tag.

OK, let’s start scanning! Where can i get a scanner?

Android

The best scanner I have found for Android is “Barcode Scanner”. i-nigma is another scanner with a nicer interface, but it only supports the most basic types of QR codes. Both are free and can be downloaded from Android Market.

• Barcode Scanner
  
• i-nigma
  

iPhone

For iPhone there are a couple of good scanners I have had recommended. Let me know if you have any better suggestions.

• Qrafter
  
• QR Reader
  

When do I use QR codes?

There is probably no correct answer for this, but I would say that when you want to take a user experience from the physical world and continue it with added value on a mobile device, it would be a good time to resort to QR codes.

Let me know if you find a good use of QR codes in your projects!

Here are a few examples where QR codes are used:

Sign a petition using this QR code in Times Square.

QR codes on graves in Japan gives you more information about the person.

Find more information about your favourite wine.

Ad for a the DVD for “28 weeks later” in London.

Find more information about this apartment for sale in Toronto.

Get more “friends” with this t-shirt!

Some cities in Norway have started to use QR-codes on bus stops. Scan the code to get the next departure from your current location. Great example of bridging the physical world with the virtual world.

Read more about QR-codes on Wikipedia.

Scrum projects are perfect for usability testing. Make usability testing an integrated part of every sprint and you will reap the benefits of usability testing throughout the project.

In Scrum projects it is usually recommended to do interface design one or two sprints before the implementation of the design. This allows you to do usability testing of the paper prototypes or mock-ups, and actually refine the design after feedback from the users before any time is spent on the implementation.

Usability testing guru Steve Krug recommends using an observation room where the developers, designers and anyone else who wants to can watch the usability test live. This can be any normal meeting room with internet access. Your first step should be to read his book “Rocket Surgery Made Easy” (Amazon). This gives a very good overview of how you can do low-budget usability testing. The setup is quite simple. All you need is…

• screen sharing software (for testing of working software or websites)
• or a camera/webcam (for testing paper prototypes),
• a microphone (for the test room)
• and speakers (for the observation room).

Set aside one morning at the end of each sprint to do usability testing. If you do the testing the day before the demo you should have a reasonably stable version, and you still have time to do a few minor fixes before the sprint demo. You can test with 2-3 users before lunch. This should be enough to uncover the most prominent usability issues.

To make things even easier you can simply use your backlog use-cases as test cases. Make sure you leave 10 minutes between sessions for you to reset your test and write up your notes, and for the observers to have a short break and grab a cup of coffee. When the test is done, you can do a short debriefing with the rest of the team to agree on the top 3 issues to fix before the next sprint.

Alternatively you can time-box the fixing of usability issues. That is, you fix as many issues as you can within a time frame of e.g. 1 day or set aside x function points in each sprint to fix usability issues. Make sure you have a specific task for this in the sprint backlog.

Whichever approach you choose, it is usually a good idea to start with the quick wins that will give you the most improvement from the least amount of effort. Often all it takes is a few tweaks, some clarification, re-wording or minor changes to the layout, to remove some of the most important issues. Other important problems are put into the product backlog and prioritized by the product owner. (At this point it helps that the product owner has viewed the test session from the observation room.)

I guess a golden rule is that you should start testing before you think it is possible to start testing. It is very easy to come up with excuses to not start testing, because you always want things to be as perfect as possible before you let any users get their hands on it.

However, the earlier you test, the earlier you get valuable feedback. Fixing usability problems while you are in the early design stages of a project is a lot cheaper than fixing them in the final stages before the release.

As soon as you have your first sketches of the user interface, you can start testing. You don’t have to do anything fancy. Just put the screens in front of a somewhat representative user (or anyone you can get) and ask them to try to figure out what it is, and how to use it. Ask them what they would do if they wanted to perform a task, such as log in, buy a product, approve an invoice, track an order etc.. Then you can hand them pages corresponding to the screens they would get to if they had followed links or buttons.

This can also be very useful in the design of expert applications. In this case you would probably need expert users in the field (as opposed to a general web page that didn’t require any subject matter knowledge). A paper mock-up is often enough to let you know that you need more information in some parts to complete an order. This can also trigger the expert user to make you aware of business and legal limitations that you have missed.

There are many tools you can use to create such simple mockups. You can draw simple screens in PowerPoint or drawing programs, but my favorite mocking applications must be Balsamiq . This allows you to very quickly and easily drag and drop user interface controls to create mock-ups that look almost hand-drawn.

Sample webpage mockup from www.balsamiq.com

Having something that looks very “incomplete” makes it a lot easier for both users and the customer to suggest changes. It may be tempting (and maybe even almost as quick) to create proper screens with graphical user controls, but the more “done” the user interface looks, the more reluctant people tend to be to suggest changes. I guess one reason is that it looks more expensive to make changes to something that looks “done” than something that looks like it has been scribbled down in a few minutes.

The testing is done, and you have several pages of notes from the sessions. Now it’s time to put things into bullet points. Right after the test sessions are done, you should summarize your notes while you still remember things. Too many times I have waited a day or two with writing up notes and found that I don’t remember what I meant by something I had written. If you have a recording of the sessions you may be able to go back through the sessions and figure out what you meant, but this can be both tedious and time consuming.

Write up all the issues in point form. Most likely many of your testers will have come across some of the same problems, and you can probably group some issues together to tidy things up. Now you’ve got a list that you can present to the team of developers. Just do a 10-15 minute session where you all agree on the top 3-4 issues that will give you the most gain from the least effort. If you are using an agile project methodology (such as Scrum), you simply put these issues into your backlog and treat them as any other.

However, if you use expert users that take part in many rounds of testing or in the sprint demos, I have found that it can help to show them that you are actually doing something about their feedback. One way to do this in a Scrum project is to have a sprint backlog item each sprint that allows the developers to use a few hours or function points to implement a couple of “quick win” fixes to motivate the end-user testers. This can be its own item or part of the user-testing item. In any case you should aim to fix the 3-4 main issues before the next round of testing.

If you complete the user testing a few days before the end of the sprint, you can have a version of the application or web site that includes most of the functionality in the sprint, while still allowing some time to fix a few of the most obvious usability issues before the demo.

If you as the usability resource on the team are also doing most of the interaction design (like me in my current project), it can be difficult to admit that the users didn’t find your design as intuitive as you had thought it would be. In my case I have had to swallow my pride several times, but of course you have to consider the user feedback and try to figure out another way to do it, or at least tweak it so that it will be more obvious to the users how t use it.

One thing is to take the critique yourself; another thing is to convey it to someone else. It can be very difficult to tell someone in the development team that their “ingenious” solution to something was not understood by the users. Usability testing guru Steve Krug suggests a very easy way to solve this issue: Let the development team follow the test session using screen sharing software and a set of speakers so that they can listen to the comments from the user. When the developers see how the users struggle to use what they have made, it is usually also apparent how they can fix the problem.

I would recommend reading “Rocket Surgery Made Easy” by Steve Krug if you would like to learn more about usability testing. There is an entire chapter called “make it a spectator sport” that highlights many of the benefits of letting people see how useful doing usability testing can be.

Happy testing!

Some of my visitors have commented that I should get a proper tagline. Apparently “Just another WordPress.com weblog” is kind of boring…

I have come up with a few possible suggestions, but I would really appreciate some feedback from YOU! :) 

I have just finished the first rounds on user testing on an expert application. The application is migrated from an existing VB6 application to a new C# application.

To allow for realistic user testing we needed to recruit (somewhat) representative users. As this is an expert application where the users need a fair amount of business knowledge, our only source of test users are the users of the existing application.

This kind of testing, using expert users, gave us a few lessons, both expected and unexpected. I will share some of our lessons through my next few blog posts.

1. Expert users of the old application, novice users of the new application

Expert users tend to focus on what they know from the old application. This involves how they are used to doing thing, including shortcuts and workarounds. The tasks they are used to perform in the old application will often take longer to perform in the new application; simply because they are well accustomed to the old application. This can make them negative towards the new application. However, with a little practice they will hopefully get just as efficient, or more, using the new application.

This is one reason to let some of the test users participate in several of your rounds of testing. As they get better at using the new application, some of their initial concerns may disappear, while others prevail and may prove more serious than you initially thought.

Just make sure you don’t confuse these expert-novice issues with real usability issues in your application.

I just joined a new project in Oslo as “the GUI guy”. It feels great to be able to focus more on usability and user interface design, and less on technical implementation. That being said, the technology is also quite interesting, and I’ll probably be doing more development as the user interface matures.

I proposed low scale usability testing at the end of each sprint to let the users go through the user stories implemented during the sprint to verify that they work well and satisfy the needs of the end users. I was very happy when the project management jumped on the idea and gave me a green light to do user testing with a few end users.

Usability experts such as Jacob Nielsen (Useit.com) and Steve Krug (author of “Don’t make me think“) argue that 3-5 users are sufficient to find most of the major flaws in a user interface. Hopefully I’ll get at least 3, maybe 4 users to participate in the testing. By doing the testing after each sprint we can test only a small part of the system at a time, so the tests will be short (around 10-15 minutes per person). This will allow the users to give us direct feedback eary in the project, so that we can address the issues during next sprint. Hopefully, this will give the users a greater sense of ownership and involvement in the project.

During the first sprints the testing will be done very low tech, with one observer and one test-computer. In the later sprints we may decide to use screen sharing software. a microphone and a web-cam to allow the other team members to obsere the user’s actions as well as facial expressions. Steve Krug argues that this kind of “live” testing is a quick and effective way to do the testing as most major flaws will be very apparent, and the team gets a greater understanding of some of the main issues.

Recording the screen, the user and the audio for later playback is a lot more demanding and takes a lot longer than doing it “on-the-fly”, so we’ll go for the budget approach this time.

I’ll keep you posted on the design and results of the tests as soon as I have something interesting to share.

Finally, my very own blog!

Now all I have to do is to find something to write about… I think I’ll go for a light mix og technology, personal experiences, fun stuff I’ve stubled upon and some random ramblings.