Date: Fri, 29 Mar 2024 05:14:41 +0000 (UTC) Message-ID: <41451577.23.1711689281465@e251daa075cb> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_22_721979518.1711689281464" ------=_Part_22_721979518.1711689281464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
With any decent-size tree, the problem is not coming up with enough task= s to ask; it=E2=80=99s cutting down a large number of initial task = ideas to a manageable set that answers our main IA questions.
Just as in conventional usability testing, we concentrate on the= most common and critical tasks, plus those that test part= s of the site that we=E2=80=99re most unsure about. But we make su= re we=E2=80=99re not hitting those too hard, lest we miss a problem elsewhe= re or =E2=80=9Ctrain=E2=80=9D our participants too well.
One of the basic tenets of good design is to make common functions easy.= In IA terms, this means making frequently looked-for things easy t= o find.
So we should start our task list with the common things our users would = be looking for or doing on our site.
If we have existing user research at hand (surveys, usability-test resul= ts, analytics, search logs), then coming up with a list of ideas for common= tasks should be easy.
We also want to include tasks that cover things that users don= =E2=80=99t need often, but need fast if the situation arises.
For example, on a mobile phone, we may not ever dial our country=E2=80= =99s emergency number, but if we do need to, it has to be real= ly easy to find.
On a website, an equivalent case might be resetting a password. Users sh= ouldn=E2=80=99t have to do it very often, but if they do, it needs to be ea= sy to find.
We definitely want to include tasks that test areas of the site that:
This is one reason why we recommend working in a spreadsheet format. As = we ponder, discuss, and argue about various parts of the tree (or compare v= arious tree ideas), we can remind ourselves to test those parts by adding a= note in the Task column:
If this mantra of =E2=80=9Ccommon, critical, and suspect=E2=80=9D tasks = sounds familiar, that=E2=80=99s because it is. These are often the = same tasks that we focus on in traditional usability tests.
The good news here is that, if we have run usability tests on our site, = we can recycle some of those user-test scenarios into tasks for tre= e testing, especially any scenario that involved finding something= on the site.
If we=E2=80=99ve done a card sort as part of our IA work (as described i= n The research phase in Chapter 3), we=E2=80=99re alr= eady halfway to creating a list of tasks for tree testing.
When we prepared the card sort, we picked out representative content fro= m our site and created each item as a card. Now that we=E2=80=99ve created = a tree where all that content is going to live, a subset of those c= ards can be reworded into tasks for the tree test.
Note that in card sorting, we typically create 30-50 cards, whereas in t= ree testing, we=E2=80=99re normally dealing with far fewer tasks. In this c= ase, it=E2=80=99s mostly a matter of choosing which of our cards answers ou= r tree-test questions best, and gives us the coverage we want for the tree.= And we=E2=80=99ll also probably need to reword those cards into proper tas= ks, as covered in Writing a good task later in this = chapter.
Next: How many tasks?