I went to the World Information Architecture Day in London recently – our UX Designer, Rog, had been before and I gladly tagged along. And as often, if you emerge yourself in a new area, you’ll get great input and learn new things by even just poking into it. As happened, even before the day started, I got some great advice.
Being asked about my motivation to attend, I elaborated that I often get quite frustrated by ordering information or data and was really hoping to get some ideas, strategies, good practices on how to find my way through the jungle and make sense of unstructured data for myself and others. And I got this great response: “Well, there are five ways to structure information.”
“Information may be infinite, however… The organization of information is finite as it can only be organized by LATCH: Location, Alphabet, Time, Category, or Hierarchy.”
So if you think books (I often think books, hey, I’m a literature major), you could order by:
- location: geographically, e.g. where the story set or which cultural context it belongs to, by origin of the author or the publishing company
- alphabet: by author or book title
- time: when the book was written, published or, as I often to do, when I’ve actually read it
- category: fiction and non-fiction, by form (poetry, prose, drama), by genre or plot (fantasy, science fiction, travel, …)
- hierarchy: by size (large books need more space), by quality (maybe Kitsch goes somewhere people won’t see it, Classics to the forefront of the shelf), by prize (valuable books to a safe location)
And of course I can mix these structuring approaches, for example I could first divide out any oversized books to go to their special shelf and than group the rest into genres and order those alphabetically.
I love this – it all doesn’t sound too unfamiliar, but finally gives me some categories to think in. Not surprising, wherever you look, you’ll find humans ordering stuff (information, objects, actions, jam jars), but now I can identify and label a certain structuring approach and can add or choose a different one if the current isn’t working.
Our very universally human attempts to order information can also be found in testing. Think for example how you might structure a Test Plan. The Test Plan holds a number of Test Suites, which are defined around targeting a specific feature (a location) in the Product, or by focusing on a certain area (a category). The Suites in the Test Plan itself might be ordered by importance (hierarchy), as might be the Test Cases in a Suite. However, some Test Cases might have to be executed in a certain order to fulfil pre- or post-conditions (time). Or, if completely independent, they might be just ordered alphabetically.
So far so good dipping into the ordering, but as with pretty much every thinking toy I get my hands on I wonder if the Mnemonic can be used as a Testing Heuristic as well. And I actually think, yes, that works pretty well: they give me a viewpoint that opens up a fountain of ideas (and joy) for me.
So if I imagine I’m shaping my testing of a new feature, and give the Mnemonic a quick tryout, I can wonder:
- location: in my system architecture, where is the feature placed? Did any of the surrounding elements or components needed to change and might need testing as well? Where is the communication flow going, are there inputs and outputs from my feature? Where will it live, e.g. are there any environmental variations that would be worth looking into like different browsers or operating systems?
- alphabet: what kind of things or objects do I have in my feature? Can I name them? If I write them down, can I group them? If I group them alphabetically, what new, random patterns do I see? What patterns do I no longer see?
- time: can I use my feature in a slow way? In a fast way, as an angry user? Many users at the same time? Are there gonna be usage peaks (because my target users are all in one time zone with a similar usage pattern)? How is the feature expected to behave over time, is there any housekeeping to do, any clean-ups of data, any caching or session timeouts going on?
- category: what are my different use cases for the feature? Are there variations I want to test for each use case (e.g. input types, preconditions, error cases)? Can I think of areas to test, e.g. by thinking about claims or capabilities of the feature? What testing types do I want to apply (functional, scalability, robustness, load, security, …)? How do I want to test it, can I apply tools, is there any automation?
- hierarchy: what is my happy path? What is the worst that could happen? What is the most important thing to test? Why? And generally: Do I think I have enough information to prioritise my testing taking into account risks, business and customer needs? And how would I want to report back?
And so goes. So what do you think, does this make sense to you? Could you see yourself using this in your testing, when reflecting on how to structure information or to support coming up with new test ideas? Are you maybe even already categorising happily away? Or do you not agree at all on the finity of the five ways, can think of another way to organise or find any category redundant? Let me know!