Things what I writ

I sometimes write nonsense about things to try and sound clever

joking aside

I rather like using real-world, but made up, examples in prototypes, wireframes, mockups and other user experience bit and pieces. I think it provides a reviewer with a content familiarity that means they are not distracted by confusing ‘Sample 1, Sample 2, Lorem Ipsum 7’ style placeholders. I mean, are those labels important, or is a reviewer expected to try and read a bit of Latin to get some context around the content blocks I’ve scattered around? Much easier to use a few scannable labels and text areas to allow a reviewer to filter and forget, rather than expect them to somehow instinctively understand that the drop-down list of ‘Attribute 1’ to ‘Attribute x’ that you’ve presented them with is just to suggest an interaction style and that the data isn’t important. Just ignore the data. No, it isn’t actually going to say ‘Attibute 1’, that’s a placeholder. Well, it will probably be ‘Edit’, or ‘View’ or something. Look, we’re getting away from the purpose of this review. etc.

However, there is another reason to use real-world, but made up examples, which is not directly out of the usability engineering manual. Its where you put the jokes. That’s not to say the placeholder text for the latest portal home page prototype for your financial services client should start with ‘There was an Englishman, an Irishman and a Scotsman…’, but there is a little bit of me that wants to leave the occasional blipjoke lying around for anyone determined enough to look at the 3pt type in the sub menu of the fly-out on page 17. Its a bit like that bloke in Blade Runner leaving a little origami joke in a abandoned lift shaft. It doesn’t matter if you miss it, but there’s a nice little subtext to be discovered if you want to.

It goes back to my final year usability engineering presentation at university which included that Framemaker clip art of people with no faces, and all I could think of doing to lift the tedium of my Jakob Nielsen thesis was to add a speech bubble which said ‘I’ve got no face’. At that point in the presentation proper, I left it unreferenced, projected on the wall, as I wittered on about interaction models for process management application interfaces on UNIX, and I saw the sideways glances to each other of my tutors and the slight curl of their ‘snapped to geometry’ mouths and I knew they’d discovered it. They sat so far forward in their chairs from that point on that I could see the labels in the necks of their C&A shirts. I knew I’d got a first.

Actually, I cocked up my computing maths module, so I only got a 2:1, but hey, who asks about your degree once you’ve finished it? Anyway, back to the jokes, for this morning I came across a rather nice one, which prompted me to blurt all this nonsense. If you take a look at the Thunderbird 3 Features page, there’s a little example image of what those evil phishermen get up to and how Thunderbird protects you from it. What I rather like about the example is who its protecting you from. Correct me if I’m wrong, but someone had a little smirk putting that example together.

listening post: foals – spanish sahara

wireframe storyboards

someone told me the other day, well, it was Chris actually, that they liked the wirefames I was working on because they told a good story. they’re not the actual words he used, it was much more thoughful and pondering on the back foot than that, but that was the gist of it. either way, that comment resonated with me, if I allowed to use a word like resonate, or resonated, because it captured the essence of what the wireframes were about. I’ve produced wireframes many times in the past that do just describe the physical location of application elements and the specific interactions that are required to be supported. you know, like, ‘this button can only have 2 words in it, it is next to the other button, and when a user presses it, the four horsemen of the apocalypse gallop over he horizon, which we will probably implement using AJAX’. that kind of thing. my preference, however, is to develop wireframes that do that, to a lesser extent, but are much more like storyboards that describe a sequence of events in a way that can be easily visualised. now, I’m not talking about a set of images that describes Avatar 2 – All Your Trees Are Belong To Us, but the storyboard metaphor works at a much simpler level where I can walk stakeholders through a visualisation of the key interactions, including detailed UI elements, that, I think, makes understanding the interactions and changes in state much easier to grok, if I’m allowed to say grok, which I just did, kind of out loud. they’re closer to design comics than wireframes, except they have wireframes in them. but with speech bubbles.

it doesn’t work for everyone. I’ll work on these with interface designers and application developers who will undoubtedly need to understand exactly how I anticipated that left-hand tab device working when it appears, in my wireframes, to overlap the chrome, or something, and ‘wanted a wireframe, not a bloody AHA video’, but hopefully, providing the context within which the interface elements sit and the describing their interaction through the storyboards, it all makes more sense than just presenting a page with a static diagram on it and saying ‘build that please’. I’ll soon see.


listening post: aha – take on me

hidden complexities

well, they’re not very well hidden. I mean, you can’t hide things you haven’t defined yet.

I’m currently developing wireframes for UI specification based on user activity flows for applications for a client in financial services which is a sentence a bit more complex than I had anticipated when I started typing it even though I suspected there were elements to it that I hadn’t even realised might be necessary in order to provide context that might make it rather more full-featured than the initial scope I had in my head. which goes some way to providing a metaphor for the user experience design conundrum I’m facing, if, in fact, a conundrum can be faced. its not an unusual problem. I’m designing a solution for a problem that can’t quite be fully articulated. as I iterate on user interaction descriptions and map out user action flows and try to develop wireframes that support those interactions that can be translated into functional requirements for application development, its clear that the initial, narrow scope for must-have features for go-live of version-one don’t tell nearly enough of the story to enable me to successfully capture all the core interactions, let alone the extended feature set that adds the value to applications that might actually convince the business that they really should use it thereby making all this effort worth making.

and this is a complex environment. it is a number of degrees more complex than most web-based, rich internet applications. as a single application that is part of a broader application framework that supports a wide range of trading activities, it is actually a quite small, discrete deliverable, but even that small, discrete deliverable, in the operating environment in which is is embedded, has an interaction model that is as big as you feel the need to define. you could easily take a number of weeks or months refining the activity flows, building scenarios, iterating wireframes and doing all those things you do to try and ensure that the user experience is as engaging and intuitive as is humanly or machinely possible and still, on each iteration, and at every review meeting, you’ll find that there is another enormous chunk of user operations that you didn’t know about yesterday and that chunk begets another chunk and that other chunk requires an altogether different contextual description to enable you to understand its operation and how the user interaction model might need to be considered if, indeed, we are to include this chunk you’ve just told me about in the initial release, which we are, because we actually want it all now.

but this isn’t a bad problem. this is a good problem. as a user experience practitioner, the reason I do what I do is that I like to solve problems and provide elegant solutions. what I don’t like to do is take somebody else’s solution and just draw boxes and arrows around it. in this case, I get a complex problem and I’m asked to provide a simple solution – an excellent user experience – and how I solve it is up to me. perfect. I’m travelling more than five hours a do to do it, and they want it yesterday, but, really, minor irritations when to put them on the balance against job satisfaction.

Archives
Categories

Share