Wednesday, February 15, 2012, 6:30 PM

Caplin will be hosting an “Agile UX Safari” in a couple of weeks. It will be a little different to the last one at MindCandy (we don’t have a tree house in our boardroom!) but we share their passion for design and development and mixing the perfect Agile/UX cocktail.

Check out the event –  We look forward to hosting a healthy discussion on all things design, UX and agile.

Does Tab Candy signal the slow death of the tab?

It’s a strange turn of phrase, but as we do more and more online keeping tabs on everything and segregating areas of interest is becoming a more and more frustrating and complicated task when using the tabs within a web browser.

We need a way to organize browsing, to see all of our tabs at once, and focus on the task at hand. In short, we need a way to get back control of our online lives.

http://www.azarask.in/blog/post/tabcandy/

Tab Candy for Firefox shows another way with groups and spaces allowing you to take back control of your web browser’s tabstrip.

Grouping related tabs into sets is interesting (you can also share groups across devices) it’s a shame it has to open a group back into tabs but I guess that’s the way it is… at the moment.

http://azarask.in/projects/tabcandy/movies/tabcandy-demo.mov

The shrink to a stack is nice, I wouldn’t be at all surprised to see Google come back with a Google Chrome ‘BumpTop browser view’. Towards the end of the video nesting and zooming within the spaces is also put forward.

Is this the start of a movement from web browser to a browser OS…  or will Google just wrap all this up into a Google Chrome bumpTop OS?

I’m eagerly waiting to see what Google + BumpTop come up with.

This is an interesting post by Anders Ramsay.

I definitely think design agility is an important skill, I think it goes without saying that if you do not have agility then you are not agile, but I also think that design ability is also just as important for agile teams.

Sometimes when we need to produce ‘presentable’ wireframes to show a client complex interactions in an animatic we’ll spend some time polishing them up; but lately we have just been scanning in rough sketches. It makes it much more obviously ‘unfinished’ and definitely leads to looser design discussions.

Often when we need to resolve design issues that come-up ‘in sprint’ we will have a quick chat with the team and produce a 10 second sketch to facilitate the design solution, job done. This is design agility to me. It does depend on the development team having at least some design ability though – luckily at Caplin our devs are all cool techreatives at heart.

On design collaboration…

Obviously collaboration is a fundamental part of the design process, but this doesn’t mean that the whole design process needs to be collaborative.

As Tim Brown of IDEO discusses on his blog about ‘Design Thinking’ being a problem solving approach, I think the same is true for UX. There are the two sides of the process, divergent (creating choices) and convergence (making choices)… Analysis (breaking problems apart) and synthesis (putting ideas together).

The skill for ‘agile design facilitators’ is knowing when and where to collaborate. When to ask for input from subject experts, when to gain insights from users and when to open up for multiple inputs. But also knowing when to downsize and focus on synthesizing the design.

Collaborative design doesn’t need to lead to compromised design (nicely pointed out by Andy Rutledge) but both the designer and the organisation need to cultivate a culture of design and trust in design, the seven core perspectives offered by Brett Lovelady from Astro Studios distills this idea nicely.

As Twyla Tharp (author of The Collaborative Habit) says…

Collaboration can be internal – an act of listening to others and then having a silent, private conversation with yourself.

Agile attitude – yes of course but with design agility must come design ability across the organisation.

I missed the start of SPA2010 on Sunday, I knew it was going to be a heavy week and I needed some time for the family Sorry Phil/Adam.

Monday started with the opening plenary, I think it was good, I’m sure it was… it’s just that I was a bit distracted thinking about our impending workshop – would it work out?

Persona Driven Development – Can it work for you?

Phew! I think the answer is YES!! the Workshop was well attended with about 20 participants. We introduced Narrative Journey Maps (NJM) and how to create them. The everyone had a go. Prezzi the zooming infinite desktop type format worked well (thanks Sarah) and the materials seemed to be fit for purpose.

After the first exercise we introduced personas and the re-ran the scenario walking in the shoes of the personas on a ‘Discovery’ session. This generated lots of ideas and demonstrated how personas can focus effort and creativity and also unify a teams understanding of the motivations and needs of users.

Feedback on the workshop was very positive. Participants liked the narrative storytelling elements of NJMs and how they visualised a complete interaction flow, a number of participants mentioned that they could think of situations at their own organisations when they would experiment with them.

Most participants were aware of personas but had no direct experience of using them, again the feedback was positive and the proof of the power of personas was evident around the room and on the walls with all of the creative ideas and solutions that were generated.

WOW time to relax and have some lunch!

Pinocchio: on becoming a Lean Leader

This session was run by Portia Tung and Pascal Van Cauwenberghe. I wasn’t sure what to expect but as the story of Pinocchio was retold in whiteboard imagery one thing became clear – this was going to be fun.

By pulling examples from the story and focussing on the negatives and the positives (bad decisions made by Pinocchio made his nose grow)… by being strong and brave (and making good decisions) he was able to become a real boy etc.

Portia and pascal quickly took us from fairytale into corporate philosophies which was an exciting and demanding ride.

Here are some key takeaways:

Lean Leadership Tools:

• Visual controls – Use simple visual indicators to support Flow and Pull
• Standard Work – Adhere to work processes
• Daily accountability – Use visual controls to improve focus and drive improvement
• Leadership discipline – Set clear expectations and maintain focus

Tools of a learning Organisation:

• Nemawashi – Make decisions slowly based on consensus, implement decisions quickly
• Hansei – Relentless reflection
• Kaizen – Review regularly to establish a stable process and make incremental improvements

All of the above is guided by the long term philosophy: Grow and align the whole organisation towards a common purpose greater than purely a financial reward.

This was a fast paced journey that left me wanting to learn more about everything, but my little wooden head can only hold so much.

Apparently there is a whole series of Agile Fairytales, Pinocchio is the first in a new series of Lean Fairytales – go check!

Retrospectives Refactored

I haven’t had a chance to attend to many retrospectives I felt they were an excuse for developers to sit navel gazing. The few I have been to were actually very constructive and a great way to reconsider ways of doing things and set up new ways of doing things to try out next time.
Rachel Davies made the case for retrospectives as a key part of the ‘Agile way’ it was a great opportunity to learn from other organisations on how they run retrospectives and we all shared our good/bad experiences.
I think the key takeaways for me were:

• To ensure that there are actionable outcomes from retrospectives

• Only take on 2-3 actions for the next sprint

• Assign the actions (ideally people should volunteer)

• Allow TIME during the next sprint for the actions to get done

I also liked the idea of not having a retrospective after each sprint (as it becomes part of the mundane) and maybe having a bigger/longer retrospective after a big feature release of tranche of work or after every other sprint.
Taking these bigger retrospectives off-site was also seen as a good thing.

End users as software engineers – Good idea? Yes but no but…

The theme here from Helen Sharp and Lucy J Hunt was that with advancements in users technical knowledge and the development of simpler tools for software development… should end users be developing software?

There were so many pros and cons around this issue that I didn’t reach a clear verdict in my own mind, and I think this was the purpose to expose this conundrum.
You could argue about empowerment and that if a user has created some little software tool to help them get their job done then where is the harm in that.

But you can counter that there are many risks that this exposes. Who is responsible for supporting this software, the hidden costs, liabilities and data loss. The fact that only one person ‘knows the code’ etc. are all up for consideration. This is all before we got on to discussing the professionalism of software development and the unmaintainability of badly written code.

Some of the tools Helen and Lucy used in this workshop can be discovered on the Voluntary Service Overseas (VSO) website within their VSO Advocacy Toolkit.

OK – well… nearly. Sarah has done a really nice presentation. But… the workshop materials are not entirely done done.

I’m not panicking too much yet – after all there are four three weeks to go!

SPA 2010 (Software Practice Advancement 2010)

16-19 May
The British Computer Society, Covent Garden London

http://www.spaconference.org

It includes some concepts from IDEO who submitted a redesign proposal back in 2007…

The comments are also interesting and focus on the fact that to an outsider Bloomberg might ‘look’ ugly, but to the actual ‘Bloomberg Users’ who are focussed on the ‘data and information patterns on screen’ they almost don’t even see the GUI.

“I have heard from traders that they don’t focus on the screens, but look for patterns within the movement and colours which then draws them to drill into specific stock. Having to relearn a system to discover the new patterns may be prohibitive for some.”
Alex Lee

This is interesting from a number of angles, as I think good UI design becomes transparent to users when it doesn’t interrupt their ‘flow state’ (this is also how I feel about really good typography… you shouldn’t really be aware of it, as you are focussed on the reading).

Comments around it being an expert/elite system are also valid… I have spoken to a lot of people who can’t get to grips with Adobe Photoshop and find it too ‘expert’. This makes the effort involved in learning the software worthwhile as expert knowledge of it becomes part of your skillset – this is true for any complex system. Most 3D software falls in this ‘expert/elite’ system group as it takes months if not years to learn the UI to a level where you can usefully implement the tool and focus on the ‘flow of creating’ rather than ‘how to use the UI’.

“It is a goal-oriented design. Clearly it is not a human centered one.
Just like a violin. You have to spend some time (ed:before) playing a tune.
So actually, it’s not bad at all.”

“But I expect to see a disruptive financial information service which can defeat Bloomberg terminal soon. As you can see, there are many thing(s) you can do much better.”
Alf

I like the comparison of learning an expert UI to learning an instrument – true we should always endeavour for a user-friendly design but exposing the complexities of an expert system (for use by experts) based around ‘Goal-Orientated’ and ‘Usage-Centred Design’, beauty may well be in the eye or the beholder:

Would you be able to pick up the violin and start playing the music in the picture?

Could you fly this plane without years of training?

An expert system is no excuse for a bad user experience – but designed around the needs of experts:

• speed of execution
• value focussed on data
• minimal interruption of flow
• tools to hand when needed …etc.

….may make these expert systems more opaque to the novice or someone outside the domain.

The criticisms of the Bloomberg screens coming from some of the UX people’s comments on this article are naive. The target users of Bloomberg are not UX designers. Before dismissing anything you have to immerse yourself in the domain and understand the needs of the experts and usage patterns within the domain – otherwise it’s just a cosmetic debate.

In terms of cosmetics the Bloomberg screens are iconic.  They are immediately identifiable as ‘Bloomberg’ – you can spot a Bloomberg screen across a trading floor because it just ‘looks like Bloomberg’.

Aesthetics? Typography?

Well yes. There may well be areas for improvement but the IDEO concepts – for me – lose the ‘Bloombergness’ of the existing screens and you’re not meeting the usage needs of your users. Like Bloomberg, we have also had to take these considerations on board when designing the Caplin Trader UX.

So… I agree totally: Let’s shake things up a bit and “Bring on the disruptive financial information service!”

But…therein lies the challenge.  Any UX for a financial trading application has to innovate whilst also meeting the usage needs (and learned experience) of the (expert users) – traders.

The UX team at Caplin are always looking for ways to enhance our Usage Centered Design (UCD) process and tools because we realise the importance of UCD in helping us to uncover the pain points of our users.

When designing/refining application ‘flow’ one of the tools we use is a Narrative Journey Map (NJM).

This is a mashup inspired by other UCD techniques combined into something we find very useful. In this post I’m going to outline the NJM process we currently use – (we are always experimenting and evolving this technique). We will also be exploring the NJM process in detail as part of our upcoming Persona Driven Development workshop at SPA2010.

Mapping

I first came across Design and Reality Maps on the (old) Sun blog (the new Sun WXD blog is here). Then I read The Persona Lifecycle and found the process outlined in Chapter 10: ‘Reality and Design Maps’ by Tamara Adlin and Holly Jamesen Carr.

Reality Maps

Reality maps are a step by step recording of actual interactions. I have found this invaluable as a baseline recording of the ‘here and now’. We do reality maps in real-time by laying down the track as we go along (we then go back and re-write any illegible scribbles).
During design/discovery sessions, reality mapping creates a neat artifact that can be ‘re-run’ with the participant (often uncovering more layers of detail with each re-run).

Design Maps

With design maps you can leave reality behind and explore creative concepts and flows. We use Design Mapping sometimes before wireframing/storyboarding as it allows you to park both ideas and open questions (highlighting creative opportunities for extended exploration and blocks that require further clarification).

As you rewrite/remove/rearrange steps, you can clearly see improvements to the journey – as ideas are abstracted away from GUI widgets and wireframe design, maps are a quick way of experimenting and ideation.
We use the following index card colour coding for all our mapping:

Green for steps

Blue for ideas

Yellow for notes

Pink for open questions

Persona Driven Narrative Journey Mapping

NJM can be used to map real user flow during design/discovery sessions, but they can also be used to map the experience from the perspective of a persona.

We take our persona and build a narrative around their goals and pain points in context, then we walk through interactions ‘in the shoes of the persona’ really bringing everything to life.

By syncing the ‘emotional experience flow’ to the journey map, it anchors known pain points and uncovers new ones. These can then be used to inform a focussed persona driven development track.

Setting the scene

We write a little narrative encapsulating the persona’s views as a prelim to the mapping exercise. Depending on what we wish to explore goals and pain points may be woven into the narrative.

Pairing: actor/observer

When producing an NJM from the persona’s perspective we have someone act out the interaction as the persona, while an observer records the interaction flow.

Encouraging collaboration and feedback

We stick our completed Journey maps on in a place where people will walk past and encourage colleagues to write comments on the map.

Re-writing the story… a happy ending?

It seems simple to go from ☹ to ☺ but in reality it can be evily complicated.

NJM can only take you so far. ‘Ideation’ is great – but we are in the business of shipping software with real benefits to our users, we don’t want satisfied customers we want delighted customers.

Extracting actionable tasks for pre-planing, theming development streams and validating the development with testing – all of this will be covered in our upcoming Persona Driven Development workshop at SPA2010.

In the end everyone loves a happy ending, and at Caplin we love happy customers. Surely this is the fundamental goal of Usage Centered Design and good service design?

The Pulse Smartpen

The Pulse Smartpen together with special dot paper and the Livescribe desktop software form the Livescribe system. The pen has an small microphone and records audio that is synced up to the writing and a OLED display showing messages/status.

You can playback your recording by clicking on your writing or by downloading the session to the ‘Livescribe Desktop software’ to replay… It’s probably easier to experience than describe. So here’s an example:

The pen has a few party tricks up it’s sleeve: you can draw out piano keys and then click the pen on the keys to ‘play’; you can write out maths problems and the pen will provide the answer; you can also write a word and then translate it, the translation appears on the pen’s OLED display. Other ‘applications’ can be downloaded from the Livescribe app store.

The dot paper

The special paper used with the Smartpen is covered in microdots a ‘digital paper technology’ created a few years ago by Anoto.
As you write, the microdots are read by an infrared sensor in the pen, pinpointing it’s position, this enables the magic bit (for me): the live ink playback.

If you have a good quality printer you can print your own dot paper from the Livescribe desktop software (so you’re not tied into having to buy the paper pads) although the nice little Moleskine-esque notebooks are rather nice!

The Livescribe desktop software

This software works OK ’stand-alone’ playing back pencast sessions, but the interface for uploading/sharing the pencasts is (I have found) problematic.

A clever feature of the software is that you can search your written notes, so for example searching Adobe will highlight ‘Adobe’ within your handwritten notes.

It would be great to have the ability to export the pencast as a stand-alone file, hopefully this will come in later versions of the software (as currently recordings have to be uploaded to the Livescribe community website for sharing).

Real-time notetaking

When using the Livescribe for ‘real-time notetaking’ one thing I noticed is that it’s amazing how you think you are listening but then realise you have drifted off thinking about or another project, an email that needs to be sent or lunch and have missed some important point, fortunately with Livescribe you haven’t missed it as the pen captures everything that is spoken – it’s just that your written notes will have skipped a beat. Also I find it’s easy to slip into writing down what is being spoken, this obviously isn’t needed as you have a recording of it.

To keep my note-taking inline with what’s being said I have adopted a bastardised version of the Cornell method. I use keywords supported with my interpretation/summary of what has been said.
I also try to use a consistent set of shorthand symbols for significant events within the notes these act as visual bookmarks within the audio:

Artefact

I use this when a significant artefact is encountered. This is useful for recalling in later interpretation sessions or when creating a consolidated artefact.

Idea

I know you shouldn’t put your ‘design head’ on when in the middle of a contextual study, but sometimes something sparks a design idea that just has to be captured… I quickly note this and surround it with a ‘thought bubble’

Bookmark

Livescribe has it’s own bookmarking system (I haven’t fully investigated this yet) but I use a star as a marker to indicate a useful soundbite that could be extracted/quoted later.

Summary

I still have a way to go refining my Livescribe notetaking technique, and I haven’t tried the transcribing software yet for tranfsorming written notes into editable text.

When Livescribe iron out the problems I have experienced with the desktop software I would use this as my default note taking tool for all my writing, until then it will remain a very useful addition to the rest of my UX toolset.

Obviously I can’t share any of our contextual Inquiry notes, but here are some UX related pencasts:

Pencasts from UXLondon 2009

Adobe UX Methods Notes from skillsMatter