Things what I writ

I sometimes write nonsense about things to try and sound clever

Building theme-based information architectures

There is often a temptation to dive into information architecture design based solely on acquired knowledge and a well-articulated business objective. It’s quite possible to produce meaningful taxonomies and content structures in this way, especially for discrete, closely scoped projects. However, some of the most effective structures evolve when iterative analysis of research findings and discussion outputs start to surface emerging themes.

I recently worked on the development of a new sales and investments channel for one of our financial services clients. A sales and investments channel in of itself is not a particularly unusual proposition and there is a depth of experience within the team that might predict some of the outcomes. We might even consider sketching out the concepts in our heads just to start the conversation, since the business objective is reasonably clear. In doing that, we might even get it done quicker than anybody planned, or budgeted for. I might even get home in time for tea.

How we really maximise the potential of the design phase is if we take the insights from a well-executed discovery phase, invest meaningful time to digest and analyse the messages we’re getting from customers, and we start to build up a picture of an ideal customer journey. I’m not talking here about spending a day in a dark room with a stationary cupboard’s worth of post-it notes and walking away with a full site map. All we should really be aiming for at the end of an initial design session is identifying those emerging themes and understanding how accurately they reflect the voice of the customer. Themes are really just a logical clustering of questions, statements and pain-points related to a customer’s interaction. Since they’re deliberately vague at the early stages of design, they’re not distinct categorisations with well specified hard attributes, but more of an expression of the customer needs and desires. If that doesn’t sound pompous enough, I’d also suggest that they often describe the soft attributes of the customer’s emotional engagement with the site, for example, ‘I’m worried about the future’, or ‘I need help on this’. Identifying these themes early provides a clear customer-centric reference when iterating into task-based journeys and navigation models.

Themes are also a great way to solicit empathetic feedback. It’s more meaningful to describe a potential customer journey to a client, for example, if they can clearly empathise with the customer. Using needs-based descriptions with more open language, through themes, it can be much easier to evaluate a customer journey than by simply referencing a label on a navigation entry point. Consider the difference between ‘Protecting my future’ as a theme and ‘Savings’ as a label. While one might not map directly to the other, there is still a much clearer expression of the customer need through a theme-based approach, which sets the context for discussion and iteration.

There are number of approaches to how we take discovery outputs and begin to build out information architectures that place the customer at the heart of the discussion. Using a theme-based approach is one of those that I rather like and it has proved successful in articulating the voice of the customer, particularly when talking with clients. While this has been a brief outline of the approach and some of the benefits, feel free to contact us to find out more.

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