1. Group Project

2. Don’t make me think Steve Krug (2006)

3. Visual cues.

4. Use conventions

5. Clearly defined page areas.

6. What is clickable?

7. Keep the noise down!

8. They’re usually trying to find something.

9. Give them signs

10. Breadcrumbs and Tabs

11. Navigation Test  What site is it?  What page am I on?  What are the major sections?  Where am I?

12. Why bother?

13. Good systems need testing.

14. Why bother? Some testing is better than no testing

15. Why bother? Early is better than late

16. Why bother? Any users better than no users

17. Why bother? Right and wrong don’t matter – informed decisions do.

18. Why bother? Testing is iterative

19. Why bother? Audience reaction matters

20. How many test subjects? 1. One test 8 users: usually finds worst problems. Often not far into the system. 2. Two tests 3 users: Test 1: Often finds less problems than in scenario 1. Test 2: problems from test 1 sort, they now can find new problems.

21. How many test subjects As many as possible + as many test as possible

22. Structure: Introduction  Who are they?  Who are you?  Why are we doing this?  Make it clear that you want their thoughts.  You want them to think out loud.  There are no mistakes.  If they are unsure they can ask you?  You don’t need to be THE EXPERT.

23. Structure: The set-up  Explain what is going to happen.  Explain what the equipment if for.  Explain that what they are doing is helping the developers.  Try and get some background information – to judge their experience.  Be a Good Listener not an expert.

24. Structure: Tasking  You have minimized the browser now maximise it.  Ask them to look at the system.  Ask them where would they click?  Remind they to think out loud so you know what they are thinking what do they notice.  What do they think of certain things.  What do they think the site is about?

25. Structure  Get them to look at the page again, what didn’t they notice before.

26. Structure  Politely keep them on track

27. Structure  Review the results straight after.  Review them and decide which ones need fixing.  Figure out how to fix them

28. Typical problems  Users unclear of concept.  Words looked for aren’t there.  Too much going on

29. Triage  If easy and quick fix, that doesn’t break anything else – fix it!  Sometimes resit the impulse to add.  Don’t add new features without a lot of thought.  Go for big, cheap wins after each round of testing.

30. Don’t throw the baby out with the bathwater,  Minor changes can have major impact – in both directions.  Don’t panic  Don’t scrap a whole project because of criticism without careful consideration.

31. Tools Screen capture software Video …just taking notes

32. Exercise  In groups 2-3 each take one of the following role:  Person testing the site  Oberserver/Observers

33. Tester Role  Just follow what the observer asks and feedback what the problems are.

34. Observer(s) Role  Settle the tester down.  Get THEIR views on the system and the faults they find.  Find as many ways as possible to get information from them about the site’s usability.

35. References  Krug S (2006) Don’t Make Me Think Berkley: New Rider