Last Friday (Nov 26), I got up early, took the bus into Cambridge, and hopped on a train down to London to attend the UX People one-day conference. It was well worth the effort.
It was good to see some familiar faces from the first event in March, and to see that there were lots of well-respected UX and IA people there to support the second one.
The day was split into two halves, with four talks in the morning and two hands-on workshops in the afternoon.
The talks were pretty good, two in particular, and the workshops were also very enjoyable. Of course, you end up wondering what the other workshops would have been like (you could choose 2 out of 5), but hey ho… I was happy with my lot. I had an enjoyable afternoon, doing a lot of sketching, guided by the talented Eva-Lotta Lamm, and then a really fun ideation / brainstorming session with other attendees, instigated by the people from AKQA.
Below are my notes from the morning’s talks:
1. “Delivering Beautiful Experiences”
Alison Rushworth (UX) and Andy Hood (Creative Development) (AKQA)
Snazzy showreels and shiny things. I’d guess that most of the audience from the commercial UX design world have probably seen all that stuff before.
So the combination they find works on projects is something like:
Creating great products with beautiful user experiences is not a about “HTML or Flash, and what about mobile”. That idea is a few years out-of-date.
Now we should be thinking about context, medium and interaction. Context is king.
We should also focus on designing something that can be used, instead of on designing something that can be built. Obviously, it has to be buildable (!), but we should aim to consider the UX and the functionality first, and then build accordingly, wherever possible. Despite all the things that can change throughout a project, the UX needs to be consistent.
Nurturing the kind of team illustrated above allows you to collaboratively assess the impact that changes will have on the UX, as the project progresses. In this case, the UX people and those creative front end developers are the gatekeepers of the the experience.
When selecting and bringing together technologies to build an experience, strive to make the “joins” invisible.
2. “The Influence of Social Media”
Richard Apps (WTG)
If you are into social media strategy and that kind of stuff, then this talk would be good.
It was unclear to me, however, where the “UX” angle came into this talk, so… not much to say!
I may have missed something, but… so did a lot of other people, I think.
My two favourite talks were in the second half of the morning.
3. “Coping strategies: UX in an Agile world”
Mark Plant (#uxplant) (Lab49)
As other people have said, it was really refreshing that Mark Plant didn’t just give another Agile 101 talk.
Apart from briefly detailing the Agile Manifesto, he only talked about ideas to manage the relationship between UX work and Agile projects.
His work, and that of his team, focuses on the commercial banking sector – lots of data and standardised ways of presenting it; lots of users who have differing needs and abilities. Sounds familiar.
(1) Approach – granularity vs complete
They tried cramming the UX work into three one-week sprints, but it just didn’t work. You end up with the same problems as a waterfall approach.
So they trimmed down the UX work the the bare essentials, choosing to drop wireframes altogether. Now, their process looks more like:
In terms of design, like we have said before, start big and broad, and work towards detail. Try to apply the concept of “reductive design”.
(2) Roadmap – feature concepts
Create features that are “good enough” to get the required functionality, and move the project into the next phase of development. As sets of sprints go on, you can design in more and more cleverness.
(3) Good enough
As a team, you need to agree what is “good enough” and what is “done” for each phase of development. This is frequently easier for technical / functional things, and trickier for UX and visuals.
Where do you set the bar?
What are your users’ expectations?
Learn from research.
(4) Before you start…
In Agile, there is a notion of “sprint zero”.
Are you really ready?
UX people should be able to say “no”. You won’t get a chance later.
(5) Pace yourself
Build momentum but conserve energy.
Form strategic alliances, and be realistic.
… for the Agile product owner.
They are probably taking a lot of flak, so work with them.
… vs. consumer.
You are part of a team that delivers.
Work together, trust each other and encourage positivity.
4. “User research as a generative partner with design”
Andrew Harder (#thevagrant) (Nokia Research)
Andrew is the Expert Review Programme Manager, dealing with upcoming / future technology and products.
He gave an insightful talk about how user research can be fed into the design process most meaningfully. His main point was that expert reviews should be a critique and not a list of complaints.
Anatomy of complaints:
- tells everything
- suggests solutions
- ignores the invisible
- documents and formalises
- shows how smart we are
- talks about one experience
Demotivational and doesn’t really help in redesign.
Anatomy of critique (preferred):
- “fillets” the findings (just give the main points, not everything)
- gives designers creative authority
- engages with the design intent
- interpersonal (i.e. face-to-face, not written)
- makes everyone feel smart
- talks about design
As an alternative, the Design Council describe a four-stage process which typically features a “double diamond” of activity, illustrating divergent and convergent phases:
“Fall out of love with your user research”.
I suppose it is a bit like how designers shouldn’t be too precious about their designs. Be prepared to prune.
“By telling people everything, we end up telling them nothing”.
So pick things out and tell a story, I guess.
Give yourself space from the research before reporting it.
Then we had a look at the Kano Model, talked about “hygiene factors” (i.e. having clean code, not having loads of needless Flash content, etc), and the need to separate design issues from development issues. Just report research, and let the designers and developers process it.