if that title means anything at all. I’m quite pleased with it, but I suspect I just completely made it up, but then I suspect Jakob Nielsen completely makes things up sometimes.
as I’m constructing multi-state wireframes for a client, we’re uncovering all sorts of user expectations that we simply hadn’t considered when we started. which is nice. we also uncovering lots of interaction issues that we didn’t know we’d have because we didn’t really know what components we’d be using. which is also nice. more interestingly, we’re finding that we’re discovering some assumptions about behaviours are not correct and that is being uncovered by the made-up data I’m cramming into the wireframes to illustrate real-life scenarios.
in previous wireframe specifications I’ve completely abstracted the data into ‘item 1’, ‘attribute 1’, ‘attribute 2’ and ‘metadata x’ type labels, which do make your wireframes very neat, which I do rather like, but don’t adequately convey to the client just what they might expect to see at a particular component or object level, in a particular state. I don’t know all the data attributes in a complex trading system, of which there probably thousands, but I do know at least the highest few levels of the taxonomy that enable me to make reasonable assumptions about what is a meaningful and relevant set of data for a given object in a given state. so I’m throwing a few of them into the wireframes to illustrate state changes and assess user expectations.
while I was thinking this would be useful to demonstrate real-life application states, I was really using it as a device to increase the comfort level of the clients, by enabling them to make the subtle change in situational awareness from abstract to operational, which sounds like a grand statement, because it is. I tried to make it sound more like a joke, but I couldn’t work out how do do that and still make the point, which I’m now veering from. what it actually uncovered is that the assumption I’d made about some of the metadata that might be attached to a particular item was, in fact, not quite correct. that’s not to say it wasn’t correct metadata, it just wasn’t the metadata that users would actually find as useful as other metadata. which is fine. that’s why I sit with the clients and clarify their expectations. but the net result is much more than just me going back over 17 pages of visio layers and multi-clicking into shape groups to select the attribute text.
the subtle difference in the choice of metadata that is meaningful at that particular state of a particular application panel didn’t just change the label, it changed the whole focus of a subset of user interactions. what we had assumed might be a focus on creation date of an object, was actually much more about the distribution of that object, meaning that we’re not tracking the object by time, but tracking it by recipient. its not when, its who. and when that change is extrapolated across functional areas such an entry points to searches, reporting, and at a more granular level, iconography and semantics around context and labelling, it changes much more than just shape 97.
so its as well that I used that real data, even if I just made it up. ‘attribute 1’ just wouldn’t have prompted the discussion. I mean, I’d be finished by now, but we’d be building something inherently broken. like my computer. which is a different story.
listening post: dj shadow – mutual slump