Personas are a tool we use at Caplin to help us REALLY understand who our users are and engage everyone in the company in building something compelling that will delight our users. No I am not talking about a sexy, gimmicky UI which when first stumbled upon people go “Wow”. I am referring to a product that seamlessly fits into the user’s life, compliments their day-to-day tasks and basically engages them to a level that they no longer can live without it.

So what is a persona?

A persona represents a group of users that hold the same goals – an archetype. These goals are not “I like to use this feature” BUT “what’s the end goal in an individual’s or company’s day/week. It’s only when we look outside the boundaries forged over time that we begin to really understand their needs. If you are passionate about doing this you will deliver products that delight.

The persona also includes people that are driven by the same motives, driving like-minded behavior with common frustrations.  Just think how powerful this is when developing a product. There will be no self-referential in a meeting room arguing, ” No, I think it should do this because that’s what I would like to do”, or “how cool would it be if we added this feature”.

EVERYTHING is referred back to the persona – does it help them achieve their goal? No? Then out. Yes, then how?  Design meetings become focused on making the persona’s life easier,  aligned to removing the pain points in their process. No swirling gimmicky feature just because the technology can do it, it has to add value to the persona.

At Caplin, we have found it has removed the ambiguity around the term “user” and has also been a great educational tool on who our users are. We are now seeing many developers refer to the persona by name in discussions and has really helped us “walk in the shoes” of our users and show real empathy during the development process.

The real power also comes when you use Personas with Narrative Journey Maps.

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.

Tired of doing the same things again and again? Why not use my personal Lazy Kit,
filled with useful time savers and ‘best practice’ principles. Give it a download and
try it on your next website design mock-up.

PSD Includes:

960 Grid system

All modern monitors support at least 1024 × 768 pixel resolution. 960 is divisible
by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160,
192, 240, 320 and 480. This makes it a highly flexible base number to work with.

.

Web Safe Area

960 x 600
This ‘safe area’ is based on a 1024 x 768 Resolution and applies to maximized
browsers (in their standard UI configuration, e.g. no Google toolbar etc…)
The idea is that you want to fit your header, navigation, key messages, and a
recent piece of content into the safe area.  This will maximise the impact of your page.
We all want users to spend a long time on our sites, but the reality is that people hit
your page and do a quick visual scan to decide ;

a)  What the page is about, is it relevant?

b) Is this interesting enough to interact with anything?

c) Should I leave immediately?

Your goal in using the safe area is to entice users to scroll and discover the rest of
the page and content,  click on your content, navigate through the site.

.

Mouse Cursors

Pointer, Finger, Grab & Grabbing

.

Spare Parts

Close Icon, Dropdown Arrow, Search Icon, Left and right Gallery Arrows,
Play Icon, Top Navigation States

.

Video Sizes

16:9 –  80×45, 160×90, 240×135
4:3   –  80×60, 160×120, 240×180

These are place holder boxes for video content that will work well
within the 960 grid system

.

Gradients

Nice Multi-point soft Gradients with curved falloff

.

Button and Styles

A few Styles that I use all the time in my mock ups

.

Lorem Ipsum Text Box

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Every
Web Designer needs place-holder text boxes to be able to balance the weight of the page
properly. Having the real copy would be even better but most of the time that luxury is
not available, as the copy is still being written whilst the designer works out the look and feel.
Try and at least get a hold of realistic Titles and Headings (this can help a great deal in
conceptual thinking and planning of page).

This text Box has about 5 paragraphs worth of text in it, just click on the text box with text
tool to expand size of box and reveal more dummy text.

.

Enjoy & Feedback

Let us know how helpful this is to you, the more we hear from you, the more we can
give you what you want for free!

How to achieve a better User Experience on Portable Devices…

As much as everyone loves big pictures for blog backgrounds or lots of  fancy
widgets or flash animations, these tend to not be appropriate on Portable Devices
(the ones i’m thinking of are;  iPhone, iPad, Android or BlackBerry).

These features which are quite neat on a desktop computer can quickly become
irritating on small screens. Yes, we can zoom in & out but that just slows us
down as we wait for the page to increase in size, and then have to scroll left and right
to read sentences that are too long to fit onto the screen. This means that often
we are just waiting for the page to load. Even on a 3G network this can be boring.

What can be done?

As usual, there are a number of solutions. Here are my favourite two:

1.) Optimise your existing site to be more fluid and adapt to users’ resolution
2.) Create an alternative theme for Portable Devices.

We have opted to go for the latter (2). Optimising your existing site to work better
on mobiles can be frustrating as you feel that you are cutting out functionality just
to be able to appease the lowest common denominator.

Other pitfalls include super-compressing your images to have a better load time on mobile networks,
stripping out any flash bits you may have to keep Steve Jobs happy, (I’m joking
of course, let’s not get into that debate again) removing drop-downs or any
interaction that works on hover. This can be painful and often leaves everyone
unhappy as lots of  “nice things” have been left out.

Having an alternate theme for Mobile Users can be very effective in increasing
the number of eyeballs on your blog. By creating an experience which is relevant
to it’s environment  (for example someone standing in the train just wants to quickly
scan headlines and get the “gist of it” and not spend time waiting for pages to load on
an already flaky connection because of tunnels etc.) you can greatly increase traffic.  An other upshot of this approach is you do not feel the site has been compromised as the “full experience” is still available.

Implementation

A great way to achieve this is a plugin called WpTouch. This plugin can really help
to improve your loading times on mobile networks.

Customising

With WpTouch’s options a bit of  CSS-ing and designing your own assets
you can customise this plugin, bringing it in line with your existing branding and
“desktop theme” and make it work for your needs. It’s very quick to implement
will make a world of difference to users browsing your posts on their phones by
increasing readability, adding intuitive touch control and keeping important
functions such as search, comments & contact forms.

So why don’t you go check out this post on your mobile?
Let us know what you think.

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?

While the distinction he draws is a valuable one, there is more of a relationship between abstraction and indirection than Shaw acknowledges; any indirection that allows for more than one significantly different implementation is in fact an abstraction of the common elements of those different implementations.

At Caplin, we feel passionately about the quality of our APIs and are dedicated to making them as good as possible. I believe that much more than any conceptual muddle between indirection and abstraction, poor APIs arise most often from poor design practices. When we are thinking about a user interface we invoke personas, tell user stories and involve UX designers. When we are thinking about a programmer interface it’s very easy to neglect these things (or their analogs) because the task can seem purely technical.

Nothing the customer sees is ever a purely technical concern.

Many APIs are carefully designed and these tend to be sane abstractions in both the programming sense and the sense that Zed accepts. Where it’s easiest to forget to do the design work is where an API is created as part of a refactoring. When you already have some code and the programmer’s focus is on adding a layer of indirection so that the already existing code can be replaced, it is easy to allow the assumptions in that code to leak out or to allow the surface area of the indirection to be far too large in reflection of technical issues that the user doesn’t care about.

We must not forget that if we really expect the customer to replace a piece with custom code then some real person will have to understand the interface and write the custom code. They need to be able to do that without understanding the intricacies of the original code.

One way to mitigate this problem is simply to be aware of it and vigilant when a new API is arising. Don’t let it happen without conscious thought. If it’s something that a customer will see then it definitely needs more design work than you’ll put in within the course of a refactoring. I’ve also found it very helpful to involve people who aren’t as close to an API to help you document it, this can very quickly throw up bad design decisions.

Understanding the definitions of abstraction and indirection is valuable, but when it comes to API design the most important definition to think about is that of deliberateness.

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