A guest post by, Franco Papeschi…

As part of my job at the Web Foundation – I am quite often working in Accra (Ghana) – helping with the creation of a solid community of entrepreneurs, developers, designers passionate about mobile as part of Mobile Web Ghana.

For this reason, I couldn’t be happier when I’ve been asked by the guys at Mozilla Labs to be one of the mentors for the HCI course at the Ashesi University College, taught by Dr Astrid Twenebowa Larssen.

The Ashesi Project

Like all other cases of present student outreach projects & collaborations, the Ashesi HCI class is hands-on working on various project topics as proposed by Mozilla Labs.

From research, to concept and design, passing through the Peak of Personas, the Brainstorming River, and the Wireframes Valley. A journey.

I joined them when they where in the middle of the creation of personas and scenarios, and they were almost ready to face one of the most exciting parts of design: the concept development. Personally, I have very strong opinion on personas: I think they are one of the most difficult part of being a User Experience professional, so I was really interested in seeing their interim results. But – before that – I couldn’t resist to try and share what I learnt in 2 years of pure concept development (that was most of my job in my previous life at Vodafone Group).

The Talk – ‘Slow Elevators: Design Is Not Just Incremental’

Reduced version of a talk that I’m putting together, I’ve tried to present the students with a perspective on how a thorough research can lead to something more than incremental improvements in a service.

It can – in fact – be used for starting from scratch with new services, elaborating what we see, hear and understand from our dialogues with ‘the users’. As a design-oriented researcher, please do not always take findings at face value. And ask yourself why these are the perceived problems…

I’ve used a very common example to make my point. It’s a story about slow elevators, to illustrate how the key to solving a problem is often defining the problem correctly in the first place.

Here’s one version of the story from the 37Signals blog.

I’ve also tried to give some practical advice to brainstormers, to make sure they had the right tools to find their way in this journey. I promise a screencast of the talk soon.

Feedback on Talk

It was nice to hear some positive feedback:

• Diana: “I learnt about the importance of involving the user in the testing phase of the project. For example, if the elevator designers had involved their users more so as to gain a better understanding of why they were complaining that the elevator was too slow, they would have easily figured out a cost-effective solution, which is to install mirrors in the elevator instead of using the engineering approach of building a “faster” elevator, which turned out to be ineffective. I also learnt that it is better to have workshops than to have meetings that solve a problem. Workshops are more active and encourage group participation.”
• Adjetey: “I loved the part of his presentation where he explained, “DON’T ASK Vs. ASK BETTER, DECLARED PREFERENCE Vs REVEALED PREFERENCE; Rather than ask, go and observe. Maybe then later ask. I found that bit very enlightening.”

My Feedeedback on Personas, Scenarios & Storytelling

With 9 groups and 1.5 hours to give feedback on the students personas and scenarios, extreme measures were required!

Astrid and myself asked the students to make their presentation clear and synthetic. On one side, this helped them to clarify what were the really important things to communicate. On the other side, it was fundamental for us, in order to focus and prioritise the feedback.

Great stuff is what I’ve seen, and I’m not going to reveal anything, yet. I’ll let the students present their final project outputs on this channel, when they are ready for prime time. If you like me, are curious and impatient – you can check out the teams latest outputs via the wiki.

Personas & Scenarios

As I’ve mentioned before, I have strong opinion on personas. They are tools for designers, developers and stakeholders to empathise with the people who are going to use their services. They are coming from abductive reasoning, and they will never be a pure photography of what is happening around (otherwise they would not be a synthesis, and would not inspire). At the same time they must be credible (otherwise it’s just invention, and it would put designers off-track).

Same is true for scenarios. All personas and scenarios were based on the user research students have conducted in the previous week, so a basic level of credibility was ensured. Most of the feedback I gave was around these 2 axes:

• Explain what is behind some superficial preference of a persona: why is she liking an old Nokia phone rather than a blackberry? If we don’t dig a bit deeper, it will be very difficult for the designer to use the persona as a driver for her decisions.
• Make the persona (and the scenarios) credible: if they are not likely and credible, the design decisions will be driven by half-baked assumptions, or excessive enthusiasm in a pre-conceived solution. In the 10 year I’ve worked with scenarios, I’ve seen so many of them created to justify a technical solution, rather than the other way round.

Resources to Build Credible Scenarios & Personas?

My 3 starting points:

• The old Hollywood’s cliché’ “All Character Is Action”: meaning that it’s much more effective to show how a persona behaves, rather than spend hours describing that.
• Kurt Vonnegut’s view on storytelling.
• The way Italian author Umberto Eco wrote some dialogues of his book ‘The name of the Rose’: making sure that a dialogue could have a realistic duration, given the environment and the context. The same is true for scenarios: how many interactions a persona can have with her mobile, while she walks between her office and a meeting room? If a designer overestimates it, it will cram the interface with features that will not be useful or usable…

What Did I Learn?

I hope students have found my presence useful. Surely this has taught me a lot.

Amongst other things:

• I have taken time to clarify what I think about the project phase that connects research and design. I have spent years doing it, but I had rarely taken some time to see it in perspective and have a position about it.
• I had one more evidence that time constraints can help: we managed to have a very productive critique session, based on on-the-fly priortising of personas, scenarios, and information.
• I have appreciated how Astrid was able to ‘translate’ my feedback, adapting it to the way she had introduced personas and scenarios. Without this role, my feedback would have been much less useful, as students wouldn’t have been able to make it fit in their current model of design.
• I’ve discovered that camcorders can fail, especially when not charged (the buck stops here!)
• I have seen that there is a generation of UX designers and researchers in Ghana, and this is great news: it’s the chance to work on solving problems with a design approach.
• I have seen that designers and developers are starting to work together. I hope this is going to happen more frequently.


Astrid Larssen introduces Franco to the class

---

What is Student Outreach?

It’s a Mozilla Labs Concept Series channel to give industry related experience exposure to students at global institutions – via co-created and collaborative Design (UX, UCD, HCI, IxD) courses.
We aim to directly work together to propose and structure a engaging course module that’s relevant to the institutions own goals, interests and timing schedules.

A number of globally located institutions are already collaborating with us on a number of interesting & challenging topics for 2011.

If you or your institution would like to get involved please contact Desigan Chinniah via email {dchinniah[at]mozilla[dot]com}