Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have questions about usability.

Is it necessary to involve the user from the beginning of the software engineering process if we want to emphasize usability?

Also, I read this previous question about usability testing: How many users must be tested when doing usability, and why?

How we can measure the usability of a web site to make sure that the website is usable?

I have a project about tourism information which pays to usability aspects with mobile devices optimization. Is the previous question still relevant to be applied on my project? Also, I'm a bit distracted with which usability testing I should use.

Thanks.

share|improve this question

4 Answers 4

up vote 7 down vote accepted

Usability is just a measure of how usable a product is. If you involve your user from the beginning of your software engineering process, then you have a higher chance of succesfully emphasizing usability of the product that you are creating. If you want to ensure that you're going to make a product that will fully meet your user's wants, needs, and aspirations, you want to use a user-centered design process, and you'll need to involve your user from product inception through to completion. If you want to use a user-centered design process, usability testing is but one method that you should use during the process to ensure that you're meeting both your users' needs and your business goals.

Early on, as you're defining what the project is, you should be doing formative user research: interviewing users, conducting an ethnography, job shadowing, diary studies, surveys, and other methods. This allows you to determine what the user actually needs, wants, and aspires to, and how your product will fit into that. Remember: your user doesn't want your product. The user wants to do something, and your product will enable them to do it (or do it better, or do it faster, or in some other way make an improvement over what they're doing now).

After you've defined what the project is and what the scope is, you should continue to conduct user research to ensure that you're meeting your stated user goals and business goals. You can conduct research using paper prototypes of your product, which will help you understand whether the workflows that you have designed are ones that make sense to your users. You can do card sort exercises to ensure that you're grouping related items together in your user interface. Card sorts and paper prototypes are also good points to identify whether you've got terminology issues. All of this is done before the UI code is worked on, because you want to make sure that you've got a solid starting point before the coding starts.

In the early phases of your project, you should use your user research and your product knowledge to determine understand which workflows depend on other workflows. This will help you make decisions about what to cut when that time inevitably comes. If a workflow is of top priority, but depends on the successful completion of a lower-priority workflow, you can use that knowledge when you're making cuts. For example, let's say you have five workflows, W1, W2, W3, W4, W5, listed in priority order. If being able to complete W1 depends on the successful completion of W4, you're more likely to cut W3 than W4 because you need W4 for W1.

After you've got a good understanding of the workflows, you can continue to conduct user research with prototypes of varying fidelity. The lower the fidelity of the prototype, the more feedback you get on its workflow and how the user sees the product fitting into their life. The higher the fidelity of the prototype, the more the user will focus on the look and feel of the user experience, and less on the workflow. Both of these are important, but you want to make sure that you get the workflow right before you get the pixels right. Having the most awesome icons ever won't help if your workflows don't meet your users' needs.

As your code comes together, you should conduct usability studies to ensure that users can complete specific tasks using your code, and you can make updates. If you've been conducting user research all along, you're less likely to get blindsided at this point by a user being entirely confused by what you've created. As more and more code is written and you get closer and closer to your deadline, it gets harder and harder to make major changes. You're limited to small tweaks.

And finally, when your code is all done, you should conduct a final study: a baseline usability study that goes through the most important workflows to determine how well you met your user goals. You can use this to form the basis of the work that you'll do in the next version of your product.

share|improve this answer
2  
I really enjoy reading your answers, thanks for sharing –  Charles Wesley Mar 8 '13 at 18:49
    
Thanks! That's very kind of you to say so. I'm glad that you find them useful. –  nadyne Mar 8 '13 at 18:52

First Point: Your First Question

You could start really early doing some guerrilla testing with paper prototypes and a really small sample (3 or 4) to get early validation on concepts and ideas.

Developers don't need to be part of this step but should be informed of the outcome if those tests takes you in a different direction than maybe you were thinking. After that phase, some more formal methods could be used and developers could/should be invited to view those.

We've always had really good luck inviting developers, engineers and other stakeholder to usability sessions. They get to see the reasons behind the changes UX is requesting/suggesting.

Remember though, as the UX professional in the group and the advocate for the user, you need to be the final word on usability testing interpretation and final changes based on the testing. Sometimes testing can lead people to jump to conclusions incorrectly, it's going to be your job to interpret the tests. You could insert the Henry Ford story about his "customers" asking for faster horses here. ;)

Second Point: RITE Method

We often use prototypes that we can change quickly based on a certain number of participants from one day to the next if those participants discovered something. We use the RITE method for this. Here's another article explaining RITE and its benefits.

Hope that helps. Usability testing is hard, but it's so worth it. Another thing to remember is there is a difference between Function and Usability.

Function = The Right Design

Usability = The Design Right

Testing will help answer both. Good luck.

share|improve this answer

Any project, even a small project benefits from incorporating usability early on. During the analysis phase, set goals and determine who will use the product for what purpose. The design phase is iterative. That is, the design team continually evaluates whether the design works for the users. Ongoing emphasis on usability throughout the Implementation and Deployment phases helps to maintain a user-centered focus during last minute changes and when planning for the next version. As you plan the project, determine what usability steps will best meet your user and business needs.

share|improve this answer

I would say yes, but the engineer or developer needs to be upfront that not all suggestions will make the cut. I have seen good ideas become bogged down because the end users added too many features and kept to the original deadline. Clutter, half-baked functionality. It did not work! I have also seen where the developers took it from the beginning, and although it met the design scope, the users realized they didn't actually understand what it was the tool did compared to what they saw it doing. Technical terms, oddly ordered buttons, common functions buried and rarely needed items front-and-center.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.