Notes from UX In The City
I was pleased to attend the very first UX in the City conference in Oxford this week. I ran my ‘Make your first UX comic’ workshop, which I have changed a bit and I was pleased to test that out. I also got to attend several very thought provoking sessions, and catch up with some good UX friends, including Dave Ellender from UX Bristol who ran an excellent workshop on social media that I couldn’t attend. Hopefully he will run it again sometime soon!
There are three main things I have taken away from UX in the City 2016:
Team Cognitive Walkthroughs
This technique was described by Simi Shaheed from Atlassian. She described how teams can already have a lot of knowledge about a product, but its not actioned or even recorded anywhere. This causes a problem when new research work is undertaken, and the results are shared. This can cause problems when team members feel the research is a waste of time – the problems are all known aren’t they?
Simi explained how she had run a cognitive walkthrough with a new team she was working with. This was due to her research results not being received very constructively, e.g: “we know this”. She paired off different team members and gave them tasks to do using the service. One person did the ‘clicking’, and the other person documented the process. Once everyone had done this, they all got together and went through the results, grouping and recording the problems. This became their team’s starting point, and gave them their shared understanding.
This approach interests me because it flattens the hierarchy of the team. It gives individuals the chance to speak freely about the problems they are aware of within a product. It also means all that knowledge (that’s not always audible) is given a chance to be shared and understood. This is a cut down version of a full-scale cognitive walkthrough in it’s traditional sense. It may not be as robust as a full one, but there is still value to be had as a team activity.
Research quality is better than quantity
Caroline Jarrett ran a great session titled “The Survey Octopus: Getting valid data from surveys”. I’m taking what I learnt here and using it straight away!
The biggest take-away for me was how Caroline explained how large numbers don’t necessarily mean anything. It is better to ask one question to fewer, more appropriate people than ten questions to a thousand less appropriate people. Less is more.
She recommended testing questions on real people before releasing them to check they work. Another great tip is to decide what number you want to know before you embark on a survey. If you don’t need to know a number, consider a different research method.
Generally, I’m not a fan of using guerrilla research techniques willy-nilly, so this approach sits well with me. The idea of getting random ‘users’ (who are not users) to give specific feedback/data doesn’t make much sense. What are you really learning? Random information.
Bad research = bad results. Both quant. and qual. research can harm products if its done badly. This should be a mantra for the user experience community. Lets focus less on fads, and more on meaningful stuff, yeah?
Respect goes in many directions
Adrian Warman and Jeroen van Geel both mentioned a theme of respect in their sessions. Adrian discussed how every member of a team deserves, and needs respect to be able to do their job. Jeroen spoke about how everyone focusses on themselves, and so expect to receive respect.
Working in cross-disciplinary teams, teams with different experience levels, or teams that involve clients, respect can be difficult to give and get. The variety of people and approaches can cause friction, which erodes respect.
These talks triggered me to consider what it means to respect oneself in a work setting. Do we all just respect ourselves too much? Perhaps we don’t question the legitimacy, appropriateness and professionalism of our actions enough. Before we demand respect, should we look more closely at our own work and ask things like:
“Am I really doing the best for this product/client?”
or
“Do I have the experience to do this?”
or
“Am I working responsibly?”
One of the scenarios Adrian mentioned was a classic. Developers can resent work done by Designers if they feel its been “chucked over a wall” at them. They’ve been treated disrespectfully, so should they respect the Designer for that treatment? Even if they should still respect the Designer as a colleague, its hard to respect that behaviour. The Designer needs to do better. We can all behave like that Designer at times. We need to be better at recognising it and respect our profession a bit more, as well as our team members.
