Date: Thu, 28 Mar 2024 17:52:52 +0000 (UTC) Message-ID: <1387023737.15.1711648372435@d6409e5f4ef2> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_14_1548198828.1711648372435" ------=_Part_14_1548198828.1711648372435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Primetime for tree testing is early in the design phase= , once we=E2=80=99ve done enough research to feel we have a good handle on = our audiences, their background, and their needs.
We start creating drafts of new site structures immediately afte= r we finish a content audit =E2=80=93 that is, after we decide whi= ch content we will be adding, updating, or deleting. While content is alway= s a moving target, it really helps to have most of it identified before try= ing to design a structure for it.
This work on content and structure can be done in parallel with conceptu= al design, but usually comes before more detailed work such as page layouts= , fine-grained interactions, and visual design.
From our research, we should have several ideas about w= hat to change (and what not to) in a new site tree =E2=80=93 not just group= ing, but labeling too.
We can then start sketching out new trees by looking at these id= eas and our list of planned content. It=E2=80=99s typical to rough= out 2-5 different trees at this stage, down to level 2 or level 3, just to= explore how they might work. We might do this ourselves, or (even better) = we might involve the whole team to get a wider variety of informed ideas.= p>
For more on creating trees, see Chapter 5 - Creat= ing trees.
In the design phase, we can increase the quality of our site tree by doi= ng two critical things:
The next two sections describe each of these approaches in more detail.<= /p>
Next: The design phase= : going wide