Information Technology, Product Development, Usability Testing, User Experience, User Testing, User-centered Design

Google recently announced the official withdrawal (or some would say the unfortunate death) of  a few products which could not deliver their promise. These include but are not limited to Google Wave and Google Buzz, which failed to create the waves and the buzz in the market. Remember, these came from the stable of none other than Google, which is a leading product vendor renowned for innovation, simplicity and user experience. Why then, do you think they could not measure up and survive? I think one of the main reasons is that they failed the litmus test. And the real litmus test for your products is when they reach the real users who use them to address their needs. Popularly called as usability testing, the user testing of your product reveals a lot of insights into the success or failure of the features you have created newly or changed in your products. In this post, I wish to touch upon a few key aspects of Usability testing that you must know, but that is difficult to know!

       

Why usability testing

Usability tests help the product owners and developers to understand the performance of the product from the user’s needs, goals and tasks. It helps validate and verify the structure, layout, navigation,interaction and overall experience. Also, they help in identifying the task related details:

  • User’s goals
  • Tasks to achieve their goals
  • Time taken to perform the tasks
  • Challenges in completing the tasks
  • Breakdown areas/points in the performance tasks
  • Confusing or ambiguous areas on the interface of product
For more details on usability testing, refer to the write-up on Usability Testing at Texavi’s web site.

User testing methods – Similarities & differences

I often hear people referring the terms usability testing, user acceptance testing (aka UAT) and accessibility testing in the same vein. While all of these may be related to product, and most often involve users and/or customers, they are different in their objectives, scope, and target audience as well. In this post, I wish to dwell upon the user testing which is also known as usability testing, and bring to fore its importance and the key differences between user testing, user acceptance testing and also market testing. Usability testing is often confused and compared with UAT( User Acceptance Testing). Sometimes people do compare with several marketing related activities. I give below a table comparing and contrasting among these various methodologies. I am sure this will be a handy reference for you, when in doubt.

Engage and test with users early

Defects and mistakes are like cubs, the younger you catch them, the better and quicker, you are at taming them. The later they are identified and closed in the product life cycle, they will turn into wild tigers and pounce upon the functionality, resulting in the failure of the products.  Same with usability testing as well. UT can be done at various phases, across the development cycle of the product. Most product companies do realize the importance of involving users in the product development, but often this realization dawns upon them much later  than required. There is not much use in testing the product with users, after it is all set to be delivered in a few days. You really cannot do much to rectify the defects identified, as the time to fix is less and the pressure to deliver is more.

So, a smarter step is to start testing the product earlier in the cycle for the user experience. This would help immensely with ample time to fix the defects and ensuring that they don’t grow too  big  to solve, much like taming the younger cubs. There is  a second advantage to testing early, and that is to enable users to have a go at the product early on and this gives them a feeling of getting engaged with the product development. This in turn makes them feel that they do have a stake in the product and that they are being cared for and listened to. Another big advantage with the early testing is to do with the development team’s readiness to accept the changes and make them quickly. This is because they did not put in a great effort to churn out the artefact and so, they are far more willing to accept changes and rework, as compared to the later stages.

Secret of success – test more!

Testing early does help in identifying and resolving the defects to settle down, but it does not mean that there will be absolutely no defects coming later into the product. Well, the fact remains that the numbers might be minimized thanks due to the early testing, but still defects and erratic decisions do seep in due to various other factors. The only way to ensure that these are identified and resolved asap is by testing more of the product with the users.  Most people have this question hovering in their mind as to how much of the product really needs to be tested with users. Well, the more the merrier. The more areas, functionality, modules and dimensions you test in your product, the better for you and your product.

Note that what you are going to test for, differ from time to time, and the level of completeness of the artefact. For instance during the early stages when you test the wireframes with your users, you might be looking for an assessment of the broad level concepts. As you move on into the product life cycle and test a complete, fully functional module of the product,  you might be looking up to users for validating the interaction, information architecture etc. I give below the  the areas you can focus on while testing the product at various stages in the life cycle.

Hope this post helped you in getting the facts right about usability testing. Don’t hesitate to write back your comments/queries. Until next post, ciao!

 

 

 

 

 

 

 

Agile Development, Business Analysis, Business Case, Information Technology, Usability Testing, User Analysis, User Experience, User Stories, User Studies, User-centered Design

Hurrah! It’s a joyous and proud occasion for all of us at the RSC and Rave. If you wonder why, well, RSC Publishing’s new content delivery platform, ‘RSC Publishing beta’ was launched today. Released as beta, which is bound to have further improvements, even as it stands today, this product is undoubtedly one of the finest platforms in the ‘STM publishing’ area. It is the culmination of various factors that resulted in the successful planning, execution, delivery of this platform. This is the combined victory for users, technology, agile methodology, collaborative team work and of course, sustained commitment and support from the RSC.

Refer http://www.rsc.org/AboutUs/News/PressReleases/2010/betaplatform.asp for more details on this.

When Taj Mahal was completed after almost a decade since the work was started, everybody who was involved in making it was excited and overjoyed to see it complete. This list included the persons who just carried bricks to the site. So also with the newly launched platform, everybody who has been part of the development project has a reason to smile today. With the beta launch, which can be equated to completing one pillar of the Taj Mahal, I think it is time for us to pause and reckon the project’s history. Being involved with the development of this platform from the beginning, I will try and give you a peep into how it all happened.

First, there was the Vision

The stakeholders at the ‘RSC Publishing’ had a dream, a shared vision of building a content platform that powers the Chemistry community with quick and easy access to the Chemistry content. Not just that, they envisaged that the platform delivers their content using superior technologies with the right user-experience. It all started with understanding their visions and expectations of the product and then we arrived at the unified product vision and roadmap.

Well begun is half done

As we discussed in the last few posts, in the software product development, if we align our processes to the users’ needs and their tasks, that product will be successful. The same happened with the RSC Publishing platform too. Right from the word go, they realised that ‘User’ is the engine that powers the rest of the product development. The team started off to gather intelligence about the users and arranged for some user studies in three different continents. Sound domain knowledge, being in the publishing industry for decades, added to the rich insights and contextual usage related data from the users. The end-result, a clear idea of what needs to go into the product and that exactly helped push the platform to the next stage.

Blueprint for the building

You cannot build a house without an architectural layout and blueprint. Similarly we cannot develop a software product without sound architecture and framework. When I say architecture, it does not mean just technical architecture. Task-flow re-engineering and information architecture also form part of laying the foundation for the product. Studying the existing systems and understanding the non-functional requirements helped build a solid technical framework, while user studies helped get closer to the conceptualisation of the structure of the user interface. Both these formed the foundation on which the entire application was built in the later stages.

Mantra behind the yantra

Can anything great be ever achieved without Technology? Definitely not, in this era of computers, and mobile phones. If Computer is the ‘yantra’ or machine, software is the ‘tantra ‘ that runs it. Here too, the right selection and implementation of technologies played a great role in ‘building’ the product from scratch. Because this platform is a content delivery product, RSC team selected a contemporary technology such as XML to help manage the complexity, volume and structure of content. Also, the selection of the content server technology played a critical role in storing the content effectively and delivering it faster. Also on the front end, superior technologies backed by integrated teams helped in shaping up a nice-looking and simple interface to the platform.

Go back to the user

It was good to have a clear understanding of the user needs and designing the product based on that knowledge. However, we cannot accomplish true user-centred design and development unless we close the loop by getting the product evaluated by users. It was again with the help of the key product owner and marketing team, we could arrange a few user tests and feedback sessions. These helped a great deal in correcting some issues which were not noticed till then.

Two teams – one goal

Hillary and Tensing could not have scaled Mount Everest individually. It is only by coming together and working together that they could achieve the feat. I think the Agile methodology’s paired programming concept would have been applied by them. In the case of the platform development too, collaborative team work has been the mantra for success. With dedicated and smart members working on both sides, RSC and Rave continued to leverage the  benefits of agile development methodologies. Continual interactions, empathy and collaborative working had proved to be the key turning points in this project.

There is only one way

And that is the way forward. With feet firmly on the ground, we are now poised to surge ahead with focus, renewed energy and the continued support from stakeholders and users. Now that the platform is in front of the users, we expect lot of feedback, comments and suggestions to come from the user community. The potential next steps are -addition of new functionality, changes to the existing features, usage of advanced technologies and fine tuning the overall application architecture for better serving the users. This would help us continue our march towards making the product better, quicker, simpler and a joy for the users and also for us, to be associated with the platform.

Here is the final score card, at the end of the play:

Users – 10 points, Technology – 10 points, Business – 10 points, Team work- 10 points! (On a scale of 0 to 10) victory to one and all. The game did not end here and now. It just began.