Thursday, April 15, 2010

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.

Wednesday, April 14, 2010

android user experience


see what I did there? no? it doesn't matter, you're not even reading this.

since I've recently twisted my own arm into spending more than 2 quid a week on my mobile phone, which was actually 2 quid a week on a sim card which was hoofed into a handset from 1999 running symbian s60 which I didn't like when I was using it and like even less now that I'm not, I've been wondering how I might somehow get into experience design for mobile platforms. I've been designing for web and web-based channels for donkey's years and more recently working on complex applications for trading platforms, but I've not really delved deeply into mobile as yet, other than the wap sites we pushed out for Sun Microsystems many years ago which amounted to 17 links in 5 languages that didn't really go anywhere, but we did make the logo really much smaller than we were supposed to, which, in itself, was a triumph of vectors and transparency.

a few weeks ago, I was interviewing for a user experience design position with Qualcomm, which was to be working on their next-generation mobile platforms alongside and incorporating brew, plaza and lots of other nice things that you rarely see in carphone warehouse, but that position went the way of many other full-time permanent user experience positions. that's to say it didn't go anywhere at all. I was phoned before the second interview to say that the position had somehow vapourised internally by law of the corporation and that they were very sorry but it just doesn't exist now so you can't do it. despite it not coming to anything it did at least pique my interest, since I did my usual copious research on the subject in order to perform well at the interview I didn't end up doing.

what has piqued me even more, if there are levels of pique, is that when I started my current position at Tobias and Tobias, working for financial services clients in the city, was the fact that not only does almost every single person on the train, on the tube, walking down old broad street or sat in bishopsgate, own, and is permanently conjoined with a smartphone of some descrption, they own, and are often conjoined with a smartphone of some other description. at the same time. and three on the go is not as uncommon as you might imagine, or at least I imagined. for at least 70% of these people, bleating into an iphone is their preferred interaction, for which the pied piper of hand things is undoubtedly most pleased, but other smartphones are available. you know that. right? and with all these smartphone appendages dangling in front of me, I feel like I'm missing a trick if I don't get some kind of experience designing for those platforms.

now I'm one of those people doing the train, tube, hammersmith, broad street, bishopsgate, liverpool street, tesco thing, I thought I really should get some kind of proper phone which lets me monitor trades on an AMOLED screen or something. or at least doesn't hang for a full minute when I send a text. since I also have a tendency to avoid technology trends (meaning, usually, I can't afford to be an early adopter), I had, a long time ago, discounted an iphone. actually, I like iphones, but anything that requires me to use bloody itunes just doesn't make it onto any list I have. apart from the list of things I won't buy that I have. and, since I'm already a google person, I was already looking for a phone built around a mobile platform that integrates all my googlist activities which of course is the moble platform that google make. it was really just a question of handsets and platform versions. which, granted, isn't an insignificant consideration. suffice to say, after I'd bought a pile of 'what mobile' magazines the size of a small child and reviewed acres of adverts with the occasional technology blog in the middle, I'd determined that the HTC Desire with Android 2.1 was the very thing. which it is.

I really rather like Android. I really rather like HTC's Sense UI, although it really doesn't do an awful lot after you've worked out you don't need to flip between 7 home screens that often. and I really rather like the Desire, even though its a bit, well, brown. all three together, notwithstanding the usual caveats around battery life, seem to support an all-round user experience that suits the way I want and need to use my smartphone to do the things I bought it for. my most basic requirement was for excellent support for multiple email accounts that exist on multiple servers. I was also looking for excellent social network integration. I was also looking for excellent clocks. truth is, limited as the Android apps store is, there's just enough there to enhance the user experience by one or two degrees. mind you, the apps bundled in 2.1 and the google support built-in, means that I'm pretty well set up without needing to go anywhere near the app store. unless I want better clocks. for which there is probably an app. called 'better clocks'.

in a nutshell, which is kind of what my new phone reminds me of, first impressions of the Android user experience on the HTC Desire are very favourable. I've had a week to do the thing where you turn everything on and then turn everything off again. I've tried all combinations of widgets, programs and shortcuts. and turned them all off again. I been through every single setting screen and religiously observed the state and behavioural changes that occur as a result and determined whether I like those changes. I've settled on a default configuration for everything. I've installed the advanced task manager to kill everything I've left running, because, excellent as multitasking is and nice as it is to have updates and notifications going of all over the place all the time, is does rather reduce the usable uptime.

next step is to work out how I might begin to design and build something that runs on my own phone, just to go through the development process. with all that spare time I have. I'm writing this on the train you know. and my tea's gone cold.

Thursday, April 1, 2010

wireframe data for situational awareness

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.