Category: case studies

Visa-eve. Anxiety.

Leisa Reichelt

I’m taking my kids out of school tomorrow afternoon to go to the Home Office in Croydon to – hopefully – get our Ancestry visa renewed so we can remain in the UK for another four years.

I say ‘hopefully’ because, despite having checked and rechecked the paperwork – to the point that it has almost become a nervous tic – and paid an enormous fee, over £4000 in advance – you never know what will happen on the day.

And I am nervous.

I’m not nervous for any particular reason, except that this process is almost entirely out of my control and is not governed by logic but by however the person we end up having in charge of our application tomorrow interprets ‘proof’.

And because, and perhaps I am making this overly dramatic, if things go wrong, it feels as though it could have a life changing impact on my entire family.

And I can’t assume that anyone involved will just apply common sense.

After all, this is the organisation that insists that every four years we reproduce a piece of paper, my husband’s birth certificate, to prove that his ancestry has not somehow changed in the intervening years.

I’m acutely aware of this requirement because the first time we applied for an ancestry visa we were in Australia. We had to apply to get copies of both my husband and his late grandfather’s birth certificates. Having acquired our visa, we gave both of these documents to my mother in law (who is good at not losing things, and who lives in Australia) and emigrated.

The first time we renewed our visa, we turned up to the Home Office in Croydon without the birth certificates – after all, they’d already granted us an Ancestry Visa – surely it was unnecessary to prove an ancestral relationship to the UK again. We were sent home without being able to even lodge our application, and to make frantic phone calls to mother in law to have the birth certificates express couriered to the UK while the expiry date of our current visa rapidly approached.

This time around, the documents are in the UK but we don’t have Pauline to rely on to not lose them. Of course, when it comes time to gather the paperwork, the grandfather’s birth certificate was there in the ‘birth certificates’ folder of the filing cabinet, but the husband’s birth certificate was nowhere to be found.

Background anxiety turns to mild panic.

Gradually I start to run out of places to look and wonder if some how it has been thrown out with the recycling. I look into options for getting another copy made and sent here – there is no way to get it here fast enough. I call the Australian consulate to see if they’ll accept a faxed copy from Births, Deaths and Marriages in NSW. Only for an Australian passport application, they tell me – apparently the Home Office won’t accept a certified but faxed copy.

I start to wonder how hard it could possibly be to forge a birth certificate.

I almost citizen arrest myself just for thinking this. I am a ridiculously law abiding citizen. How has it come to this?

Days pass. The birth certificate can not be found. I can’t sleep. After a few more days I start getting severe diarrhoea (Sorry, gross I know, but who knew this was a really common manifestation of anxiety. Not me.) I start to get really dehydrated.

I think about what will happen if I can’t find that birth certificate – I will lose my job. Might my family be deported? Or detained? I worry about my children.

I already feel like a bad parent for deciding it is too ridiculously expensive to get us all Indefinite Leave to Remain, then citizenship. We’d planned to do that so the boys, who were born here, might have the right to live in the UK even if we return to Australia at some point.

Then they put the fees up again in April, and at over £7000 just for Leave to Remain and the rest to get Citizenship a year later… for us it is too much.

All that time I’d spent making a spreadsheet of the times we’ve traveled out of the UK in the last nine years (frequently!) has been wasted. I will probably put our UK Knowledge Test certificates in a frame somewhere though, as a memento of all the random British trivia we now know.

So, I threw out the paper form for the Leave to Remain application, printed out the 70 odd new pages of the FLR(O) paper form, and switched to just renewing our Ancestry visa.

And, after a final weekend spent searching, the birth certificate reveals itself.

That bloody birth certificate that they shouldn’t need to see yet again.

Sleep returns and after a few days my digestive system returns to normal.

But, until we get those new Biometric Residents Permits in our hot sticky hands, I will be feeling anxious. Muscle clenchingly, stomach sickeningly anxious. As I have, to varying degrees, for weeks now.

I’m an educated, English speaker who can afford (just) to pay the fee to renew our visa and a little extra to get an appointment to get it done on the day.

I can’t bring myself to send all our identity and travel documents off for an indefinite time having heard so many horror stories of lost passports and visas that take a year to be granted.

I’m pretty good at handling stressful situations, I don’t tend to suffer from anxiety in every day life.

If I feel like this, if I can get ill from this process, how do the very many people who have none of these advantages feel as their visa expiry date approaches? How do those who are more vulnerable financially and emotionally manage?

I can hardly bear to imagine.

These things, these ‘government services’, they are life changingly important.

Devastatingly important in many cases.

They are process diagrams and routine tasks for people on the inside, but when we are on the other side of the counter they are the exact opposite of routine and mundane transactions.

It is a powerful reminder of why I do the work I do, and how very much there is left ahead of us.

 

(Embargoed until after we successfully returned from the Home Office, because, you never know…. Turns out we still have to wait a while for the BRP cards to be sent out.

Already I am post-rationalising this experience and wondering why I was so worried about it. From your distance you might do the same. Doesn’t change the fact that, rightly or wrongly it was a hugely stressful experience.

Anyway, Britain, you are stuck with us a while longer. Thank you for having us.)

Opportunities lost – AlphaGov

Leisa Reichelt23 Comments

AlphaGov Homepage

I’m sure that many of you will have heard about the very worthy Alpha.gov.uk project, the first prototype of which was released earlier this month.

If you’re a user experience practitioner, this should particularly interesting to you.

By way of a quick background, the AlphaGov project was formed in response to findings from a report by Martha Lane Fox, Revolution not Evolution into Government online services and opportunities to improve. (As a tangent, I’d love to see her in a cagefight with Lou ‘The redesign must die‘ Rosenfeld)

In this report she recommended the introduction of

“a service culture, putting the needs of citizens ahead of those of departments”

The AlphaGov project responded, setting out two overarching objectives:

  1. To test, in public, a prototype of a new, single UK Government website.
  2. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.

See. It doesn’t get more UX-interesting than that right? It reminds me quite a bit of the D7UX project I worked on with Mark Boulton and the Drupal community, so I’ve been following it’s progress with a keen interest.

Now, go have a play with the prototype and see what you think. I’m actually not going to comment on the UX of the prototype today, partly because it’s actually quite difficult to do so. I’ll get to that later.

What I want to talk about today is the responsibility that playing out a project like this in public brings with it and how, in my opinion, AlphaGov have let down both the UX and Inclusive Design/Accessibility professional communities.

What you do, not what you say

Let me start by saying that I have a lot of admiration for the the ambition of this project. There is a lot that is good about it. There are also a lot of smart and talented people on the team.

The first thing that strikes me as strange is that on a project that claims to have an obsession with meeting user needs, the team contains a visual designer and a content strategist, a general strategist and multiple search analysists but NOT a user experience lead.

That’s right. We have an obsession with meeting user needs but not so much that we’ll actually hire someone who has extensive experience in actually making that happen.

Now, the project was fortunate in that it had Richard Pope, who I first met when he was a very UX-savvy developer at Moo and who  played the Product Lead role on AlphaGov. As far as UX resources go, you could do a lot worse.

The team also recruited Paul Annett later into the project. Paul also has some UX experience but, as I understand it, his role was primarily as visual designer, making the interface a nicer place to be.

Without commenting on the interface itself, the lack of a rigorous approach to user experience is very evident in the way that the team talk about the work that they have done and their ‘design rules‘.

In a recent blog post about their agile methodology Project Manager Jamie Arnold describes exactly what this ‘obsession with user need’ entailed:

We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report.

We ended those two weeks with a list of prioritised user needs (based around search analytics from Directgov, Hitwise and departments),

We roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.

Crucially also there was a fair amount of @tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints.

More than good enough, eh? For many projects this would have been more than they ever had to work with.

But this is not just any project. This is a groundbreaking, whole of government initiative that claims to take a User Centred approach and be obsessed with knowing and supporting the end user need.

I think a project like that needs to demonstrate User Centred-ness a little more rigorously. For example.

Who is the audience?

At no point that I saw did the AlphaGov team ever apparently think deeply about what kind of an end user they were going to prioritise. They talk about ‘thinking about who our users were’ and having a ‘user-base of all the entire adult population of a country’.

As User Experience practitioners we know that although you might want the whole country to use whatever you’re designing, you need to put a ring around the kind of users you MOST want to support.

As designers we always privilege some behavioural attributes over others, even if we don’t articulate it. By not thoughtfully articulating this, you risk either an incoherent approach to the experience design or resort to self-referential design (designing for your own behaviour – something that is incredibly difficult to overcome).

You can’t take a User Centred approach to design when your user is ‘Everyone’. You need to define who your users are. You must clearly identify the behavioural characteristics that you most want to support and focus on designing to best support these.

There are many valid design approaches that do not require such a clearly articulated definition of the end user, but these are NOT user centred approaches. Thinking generally about ‘users’ while we design is not doing user centred design. I think it’s pretty irresponsible to suggest that it is.

AlphaGov sends a message that you can say you’re doing User Centred Design but you don’t have to show any evidence of a UCD process – audience definition, research, user involvement, design principles that actually track to specific behaviour attributes.

For example, it would have been great to see some personas developed and shared for this project – even hypothetical ones that drew on the data/insight available to the team. As well as helping the team avoid the problem of the ‘elastic user’ (particularly problematic when you do think your target audience is everyone), it would also help us be better able to evaluate what is good and bad about the prototype. It would also have demonstrated that the team was actually practicing User Centred Design.

(Elastic user, for those not familiar with the term, was coined by Alan Cooper to describe the way that while making product decisions different stakeholders may define the ‘user’ according to their convenience, often resulting in self-referential rather than user-centred design. More here).

This leads us to one of the complexities of the AlphaGov audience which is that, in reality, rather then being obsessively user-centred, the project had two competing audiences. The largely undefined end user and, often more importantly, the stakeholders who would ultimately decide the fate of the project – public servants. These two audiences have VERY different motivations and goals for this project, and the impact of the latter on design decision making was never clearer than when the accessibility topic came up.

On Accessibility and a conflict of interest

Again, from what I know, there was no formal expert accessibility (or inclusive design as I prefer to call it) consultancy on the project team. This is not to say that the team didn’t have quite a bit of knowledge about the mechanics of accessibility (the impact of technical decisions on whether something could be certified ‘accessible’).

The team sets out a really thoughtful understanding of what it takes to make a service properly accessible:

Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features – especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You’ll probably want to know the facilities at the test-centre).

Ultimately, the AlphaGov prototype doesn’t make any significant attempt at achieving accessibility (particularly making a site that works fine even with JavaScript is switched off) apparently due to the short timeframes and ability to ‘retrofit’ accessibility later (hrm).

Actually, what I picked up from discussions about this on Twitter and elsewhere was that actually, it was the other target audience – the stakeholders – who most influenced this decision. If they put the focus on accessibility, they’d have to take away some of the ‘shiny’ – AlphaGov would end up feeling like Just Another Government Website. Rightly or wrongly, the shiny would help excite the public servants to approve and fund a beta version of the prototype.

Perhaps it was a noble sacrifice… who knows. Point is, it’s far from transparent.

The message that the world takes away from this exchange is that accessibility, even when your audience ‘entire adult population of a country’ is optional. And that accessibility can be ‘done later’ not, as they had first set out, built into design considerations from the outset.

These are really bad messages to be sending and, given how publicly visible and lauded this project is, sets the work of many amazing inclusive design specialists back considerably.

It’s hard enough to sell in good accessibility work already. AlphaGov just made it harder.

Activity Based Design and Search Analytics

OK. So I will talk briefly about the prototype… but mostly to discuss how the data you have access to can significantly shape your design.

The team have published very little information on the data that has guided their design decision making for this project but we do know that search activity has influenced it heavily. A team of sixteen people included no UX lead (sorry, did I mention that already?) but two people doing search analysis.

In the design rationale blog post, Richard Pope implies that search logs strongly influenced the design and information architecture strategy for the prototype.

we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make

Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks.

Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls.

If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at.

It is really difficult to evaluate this prototype from a user experience perspective, given the competing target audiences. The best you can do is try to recall the last few times you interacted with a government website and try to reenact that here. Every time I do that I come away with a lingering feeling of disengagement. There’s something that search logs probably don’t really show which is that this is MY government. For better or worse, I have a long term and multifaceted relationship with this government and yet, every time I encounter this site it (by design) makes me feel as though this is my first visit. I find that really unsatisfying and kind of perturbing.

Now, this is not a professional design critique, this is a qualitative research data point of one. But it’s not something that you’ll ever pick up from search stats and analytics. I could bore you further with how I find the promise of localisation with this infinite noob status even more perplexing, but you’d have to spend time with me to understand it. And then spend some time with a bunch of other people to see if this is a common theme or just me being an edgecase.

And people will never post this kind of feedback on GetSatisfaction. (Most people can’t really articulate this kind of weird feeling and wouldn’t think that it was important enough to comment on compared to, say, a bug. You need a good facilitator to extract this kind of data).

To do really good user experience design you need a mix of data points. If you privilege one set of data, you’ll see that in your design. I think we’ve got some of that going on with AlphaGov.

Quantitative data is fantastic. I’d love to see more of what the team had to work with and how they applied it in their design process. But it’s just one kind of input. Qualitative research helps you better understand your end users and thereby to design better for them.

People who do User Centred Design do Qualitative Research.

User Experience is a Time Soak/Non-Agile

Which leads me to the final problematic sub-text that I felt emanating from the AlphaGov team which was essentially that ‘we’re as user centred/accessible as we can be given that we only have 10 weeks to build this thing’. This perpetuates the myth that User Experience can be a time soak, that it slows you down, that it doesn’t really have a place in an Agile methodology.

This is where having an experience UX practitioner on the team from early on could have been helpful.

It is certainly true that historically, Agile and UX have had a fairly vexed relationship but these days many practitioners are experienced and adept at including both user research and ux design into the most demanding agile iterations. We have a toolkit of lightweight qualitative research approaches that work beautifully in this kind of fast paced and responsive environment. UX does not have to be a laggard either at the outset or in the throes of an agile project.

The ten week project timeframe is absolutely no reason to not include real practice of user experience in the process. You may need to find someone who has experience working this way (not all UXers find this kind of project much fun), and you may need to be creative in the way you structure the work, but you should definitely be doing it. Particularly if you’re setting an example of how projects should be done, as the AlphaGov team certainly was.

In conclusion

I want to repeat again, this is a very worthy project and many of their design principles are, I think, sound. For many commercial projects, the methodology that they’ve applied and shared is absolutely appropriate. But the bar is set higher here.

By doing this project in public, by making such a big deal of putting the end user needs and their importance to the project, the AlphaGov team have set themselves up as rolemodels. They’re sending messages about the the way things should be done. They’ve made quite a rod for their back.

If I was just a member of the community, I’d probably be nothing short of delighted with what they’ve achieved. Unfortunately, as a User Experience practitioner, I feel kind of glum. This project has talked the talk of caring about the end user, of placing their needs at the centre of the project and above the needs and desires of government, but at every step, they’ve done little to set a good example for how others should actually do this.

I hope AlphaGov does move forward into BetaGov.

But I hope, if they do, they take a moment to think about what the public performance of AlphaGov and then BetaGov means for their professional community.

Either stop calling the project User Centred, or hire someone to really focus on user experience and do more to share how they’ve integrated real user insight into their design strategy and implementation.

There’s a big opportunity to set a good example to a big audience here. Let’s take advantage of that opportunity and show the UK Government, digital industry, hell, the whole world what projects really look like when they’re user centred, – that they don’t have to be cumbersome, expensive and slow.

Imagine that, a properly user centred government website that was agile, and shiny and amazing. Now, that’s something to get excited about.

A template for intensive design

Leisa Reichelt5 Comments

I was recently speaking with a potential client about a project that I very much wanted to work on. Due to scheduling issues (theirs and mine) we ended up with one week in which we could both be available to work on the project. At first, it seemed like the logical thing to do was to walk away and hopefully refer them to someone else with more time on their hands… but we really wanted to work together. We started thinking… could it be possible?

And so it was that we ended up working on one of the most intensive design and research projects I can remember working on. It was hard work, but good work and – in the end, we got the job done. I thought it might be useful to share the format we used so you can consider potentially this approach if you find yourself in a similarly time challenged situation some day!

Important note: this is not a sustainable way of working. You can do this for a week, you can’t do this week in, week out for a year.

The challenge:

We started the week with lot of data/content in a database, a target audience (digitally excluded), a content management system (SharePoint 2010), an accessibility goal (triple A) and a logo.

We needed to end the week with a high fidelity prototype that could be taken into production the following week.

We wanted to do this taking a user centric approach, ensuring that our concepts were evaluated by members of our target audience throughout the design process.

The team:

It was evident from the get-go that this was going to take more than me. I’m a freelancer, so this mean that I had the pleasure of hand picking a team to work with me on this.

I asked Mark Boulton to help bring our prototypes up to high fidelity. Mark & I have worked together a bit in the past and he is really comfortable in that grey area between wireframes and finished design – this is an area where designers can butt heads a little, so avoiding that was going to be very important in this project.

I also asked Andrew Travers to be the second UX designer on the project – I knew we’d need two pure UX people on this project as we were aiming to both design and research in the week. Andrew brought some brilliant subject matter expertise and accessibility know how to the project, but more importantly, he was brave enough and flexible enough to contemplate such an ambitious/slightly mad project plan. (Andrew has also written up his thoughts on this project).

We pretty quickly realised this was a great opportunity to invite an intern to work with us. Not only could we really use an extra set of hands, it was a rare opportunity to see pretty much a full UCD project in the space of a week. We were thrilled when Lisa Drake took a week of holidays from her job to join us. It was a great decision – both to invite a mentor and to choose Lisa, who was fantastic.

In addition to this we also had four members of our client team on site for the entire week including decision-making-enabled representatives from marketing, content, technical and their project manager.

Finally, we had a daily call scheduled with the Shaw Trust who were going to review our work each day and make sure we were on top of any accessibility issues that emerged as our prototypes developed.

The venue:

We needed a space that would allow for our team to be onsite, to do workshops, design work and to conduct research. We booked some space at the London User Research Centre: a research lab and observation room and another workshop room with day light. This gave us the research facilities we needed and enough flexibility in the space to be able to accommodate the range of activities and people that we needed to house in the space of that week.

On the final day, we de-camped back to the client’s offices to wrap up our work and prepare for a presentation to the larger client team.

The format:

The general shape of the project was this:

  • 1 day of UX ‘foundations’ and initial concept development
  • 3 days of prototyping, researching, iterating
  • 1 day of completing templates, annotating and preparing presentation
  • a day or two in the following weeks to finalise any outstanding work.
  • 3x UX resources for all 5 days, 1x ‘visual’ design for the last 4 days (+ several extra days in following weeks)

The general shape of the day tended to be:

  • project team ‘kick off’ meeting in nearby cafe around 8am
  • full team kick off in labs around 9am
  • work, work, work, work, work,
  • full team debrief at end of day
  • project team continue work/debrief at pub/over dinner that evening.

Preparation:

There was limited time for preparation, and this largely consisted of agreeing a recruit brief for research, briefing recruiters, reviewing existing materials that the client had (mostly from an aborted previous attempt at this project), and project planning – working out a rough idea of what we were going to do on each day and a fairly specific plan for day one.

Day one: UX Fundamentals

This day had to provide the grounding for the rest of the weeks work – we needed to:

  • clearly articulate the value proposition
  • clearly identify and describe the priority audience(s)
  • understand the primary scenarios of use  that we wanted to support
  • come up with some concepts for how we might present the our content to this audience to support these scenarios in a way that clearly expressed and supported the value proposition.

Our approach to the first three items entailed extensive use of post it notes, individual brainstorming, collaborative affinity sorting and prioritisation. Our approach to the final item involved a lot of group sketching (including our client team, of course), discussion and ranking.

As we left the lab at the end of the first day we did have a couple of concepts we were going to move forward with but we weren’t feeling particularly inspired by them. Upon decamping to a local pub that evening (in preparation for meeting and briefing Mark who was joining the team that evening) it became clear that we had quite a bit of affection for one of the concepts that we’d dropped while in conversation with the client – it was perceived as a little too risky. Over a pint, we did a little more work on this concept and got it into a sufficiently good shape to include as an option to present in research the following day. We then went to get pizza and bring Mark up to speed.

Day two:

After our morning kick off, Mark took the client team off to start work on the ‘look and feel’ of the site, starting with a mood board exercise. Meanwhile, in the observation room, the UX team were frantically building prototypes of 3 concepts (using Flairbuilder, mostly for speed) and preparing a discussion guide in time for the first research session at midday – the first of 14 interviews scheduled in this next three days.

By midday, three very rough prototypes and one very unrehearsed discussion guide in place – the research began. We saw six people in the rest of that day – tag teaming research between Andrew & myself, clients watching every moment of the interviews, and design happening on the fly meaning that no two participants saw exactly the same prototypes.

By the end of that day, we had learned a lot. We’d abandoned one concept entirely, introduced another, were pretty sure two concepts were not right and that the concept we’d rescued in the pub the night previous – the risky one – was going to be the right way forward – but it still felt a little scary. We needed more evidence it was right. We didn’t have much to show the Shaw Trust for them to advise on.

That night, we were all pretty nervous.

Day three:

Four more research participants today. At some point it becomes evident that the ‘risky’ version is definitely the way forward. A whole range of participants have now managed to identify personally with it (beyond our expectations) when our initial fear was that it would be alienating. We leave Mark to grapple with increasing the fidelity of the design and move onto tackling the more content rich templates and, as it turns out, the content itself.

We uncover a range of information architecture issues, particularly around terminology/labelling on a freshly ‘redesigned’ content model, we completely reshape the way the content is presented and in the process get very excited about a fancy faceted navigation system.

The Shaw Trust remind us that people with cognitive disability will struggle to make sense of our fancy faceted interface. We realise we’ve gotten excited about an idea and forgotten about our audience (who are not necessarily cognitively disabled, but who are the least experienced web users). We prepare to kill our darlings.

Day four:

Another four participants today. Having sketched all the way home yesterday and back again this morning, over coffee before our kick off meeting I have a feeling I may have replaced yesterdays darling facets with a much simpler solution that properly matches the needs we’re hearing coming out of research.

Our clients are more energised and excited about this project than they were at kick off and this is in no small part due to them having the chance to actually witness the people they work to help every day, actually using the system we’re designing for them. These people are stepping out from behind stereotypes and suddenly feeling a lot like us – but with the specific needs they have more clearly articulated than ever.

We test the newly simplified data-rich interface and struggle to keep a straight face when the participants describe the hard to make sense of page they’re expecting to see, then react with visible delight when they see our stripped down page, designed to focus specifically on the content they are seeking. (You don’t get those proper delight moments often, we cherish those).

We copy and paste ‘high fidelity’ designs into our prototypes as parts of them are ‘ready’. Headers and footers first, then bits of content as it starts to feel like it’s working.

We’re having all kinds of difficult discussions with the client about corporate colours and logos, but we’re also able to test our variations as we go – to understand which fights are really worth having and which are less so.

Even now, we rarely show the same prototype twice. Constantly refining.

We leave the lab on day four feeling pretty amazed at how confident we feel that we’ve actually, really cracked this. That it’s actually going to work.

Day five:

We’ve got a meeting room at the client’s offices. We make a window full of post it notes of outstanding tasks, we prioritise and allocate the tasks. We make tea. Lisa, miraculously, produces a packet of chocolate biscuits.

We work as fast as we possibly can to work through the details of the templates, to make sure we can map the database to our templates, that we can make any ‘massaging’ that needs to happen to the content relatively painless, that we’ve thought through various states and orders in the flows.

We put together a presentation of the work we’ve done over the past week, our rationale and our designs. We do this so quickly it takes less time to make the presentation than it does to give it.

We kick off our presentation by showing some of the profiles of participants we’d met that week – young single mothers, people suffering from mental illness, people who are now or were recently homeless, or in prison. People who really need us to help make access to services easier to find – especially as more and more of those services go online.

Our client is happy with the work we’ve done, but we’re not really surprised because they’ve been there, with us, helping make decisions and seeing how and why decisions were being made the entire time.

Wrapping up and next steps:

Not everything happens in a week. The following week we put the wireframes into a more formal document with annotations and some notes to capture the general principles of the design approach and content strategy.

Mark has more work to ‘design’ all the wireframes into developer-ready templates. We’re still struggling with the homepage … we know the components that need to be there but getting them to work visually is tricky.

We do a handover meeting with the client to talk through everything including any questions they have outstanding. There’s a bit of work required to properly map the database to the templates. We agree there is a whole other project required to look at the information architecture and bring it into alignment with our new findings and approach.

What we learned:

  • your team is everything – you need a good, flexible, friendly, committed team to work this way
  • having the client on site is invaluable. This approach would probably not have worked (or at least, worked so well) if they hadn’t been there participate, observe, field our questions, respond to our challenges.
  • you don’t need to sacrifice research just because your timeframes are short. You will have to be flexible and not get hung up on process, but you will learn what you need to make good, informed, decisions. Also, you give your client the opportunity to see their ‘customers’ in real life. Both of these are invaluable.
  • although you’re in a hurry, you need to take time to communicate.
  • if you want to work like this you need to be brave and confident, you can’t be a perfectionist, you have to be careful with your client seeing you making mistakes and being wrong (all part of the process)
  • not only does an approach like this work but it works well. As a team, we were inspired and energised and felt we’d probably done some of our best work because of the way we were working not in spite of it. I think we’d all be keen to work this way again. (As soon as we get leave from our families who we saw very little of that week).

Photos by Lisa Drake. Thanks to Start Here for being brave enough to work with us this way!

Take care of the pennies, Yahoo…

Leisa Reichelt3 Comments

Yahoo have been copping a bit of strife lately about the way they’re running their business. Think what you will of their business strategy, the thing that bothers me the most is that I’ve been trying to give them money for Flickr for a couple of years now and failing abysmally. Every now and then I go back and check, thinking that surely they have fixed this revenue leak by now, but as of this morning, they’re still not allowing me to give them money for their service.

I reckon they’ve missed out on at least $50 from me, which is not much I guess. But I’m far from alone.

What’s the problem? Well, it’s a two stage thing. If I’m missing something obvious (and with that, two years of pro-membership) please do let me know.

The first problem – I want to pay with my credit card.

The credit card I previously used has expired (as they do). The only option I’m given around credit card payment is to EDIT the card, which I select. In order to proceed I then have to re-enter the card number OF MY EXPIRED CARD! Now, show of hands, how many people actually hold onto expired credit cards and would actually be able to complete this task? Anyone?!

larger image here.

After going backwards and forward searching for the part where I can simply add a new card I give up and go to plan B – using PayPal. I use PayPal all the time, I used it last week on eBay and it worked fine. And yet, when I try to pay for my Flickr account using PayPal this is what I’m told:

larger image here.

‘The email you entered is not associated to this payment agreement you are trying to confirm. Please try again’.

That isn’t even a sentence, right? I think I get the gist of what they’re saying but even with my advance PayPal skills (I moved from one country to another and still have a PayPal account – anyone else who has done that knows exactly how much more you know about PayPal than you ever wanted to) I’ve tried everything I know and can’t get this to work.

At any rate, I’ve now spent way more time on this than Flickr is worth to me. My once great love of Flickr is now dead. Yahoo has not only lost my $50, they’ve also lost my emotional connection to their brand and my previous evangelism – worth way more than all the pro subscriptions I’d ever pay in a lifetime would be worth.

But – here’s the point of the story (because I don’t really want to waste your time moaning about one company’s crappy user experience, where would we stop!) – this is a revenue point. This is a place in the user journey where money changes hands.

If you have a product that has interfaces like this – places where people are giving you money – please pay particular attention to them. Make sure they are working. Make it as easy as possible for me to give you my money.

There’s an old saying, ‘take care of the pennies and the pounds will take care of themselves’. I don’t think it’s entirely true – I think the pounds actually need their own special UX strategy but having lots of pennies come into the coffers to support us as we come up with great new ways of making lots of pounds is eminently sensible and a great way to STAY IN BUSINESS!

Don’t let easy money like this leak away. If you have interfaces like this one that might also be leaking, go check them now.

And, while you’re at it, make a note to check on them regularly.

Meanwhile, if you want to see my baby pics, I’ll be over at Facebook. I’m still looking for a new place to share my UX pics. Suggestions welcome.