globalful

what we am are

commercially viable interaction design mastery

as this train slips by the half lit empty warehouses on the edge of town, imagination rustles the carrier bag of existence. I had a vivid dream last night about travelling on a train that gets cut lengthways from front to back as I’m travelling on it. just as I was about to extract meaning from that dream, my alarm sounded, like the distant call of a train, because I had to get up to get a train. the recursion of circumstance contained in those few seconds demanded that I extract some kind of metaphor from it, but try as I might, there really wasn’t one. maybe something about a train of thought (stabs self with pencil of despair).

I met with a very bright person today who is very interested in pursuing a career in interaction design. so keen that he is pursuing a masters degree in interaction design. and while he is doing that masters degree, he would rather like to get commercial experience in practicing interaction design. upon discussing which, I suggested it would be very good if this could somehow enable us to better inform the curriculum for a masters degree for interaction design such that it enables graduates to be commercially relevant and employable because christ knows commercial design companies are forever moaning about academic design curriculums not being commercially focused enough and the irony of the recursion of him needing commercial experience to be commercially viable while suggesting we can somehow use his experience to inform the structure of a commercially focused interaction design course is not lost on me although most of that sentence possibly was.

I bought a paramore album yesterday. I can’t explain that at all.

listening post: my bloody valentine – only shallow

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