UX London 2015 — Our top 3 takeaways

By Heather Bayfield — Product Manager, Kotikan

From 20 to 22 May 2015, Designers and Product Owners flocked to UX London, a conference tackling current trends and tricks in the world of UX. We were lucky enough to be among them and here we share our top 3 themes from the event, as well as the talks we recommend for learning more.

1) Create products which are not just user-tested, but user-defined

While it is important to validate user assumptions by asking questions relating to specific objectives, it is also important to engage with users informally as they go about their day-to-day lives. This lets you see what topics users raise and how users expect to find what they’re looking for in an app. At Kotikan, we find that every one of our regular user testing sessions brings up at least one point we hadn’t considered, helping us create user-defined products.


Speak your users’ dialect.

Presenters such as Kim Goodwin (@kimgoodwin) and Cecilia Weckstrom (@ioedge) highlighted the need to speak the language that users use. Don’t just assume you can come up with names and terms that will resonate with your users, let them try out your product and see what terms they use to describe it. Be positive and engaging — if you’re making a mood app, ask “How was your day?” over “Please fill in today’s mood profile”.

Users’ mental models should define the information architecture of your product.

Uncover user expectations with techniques such as card sorting and let it be the users who help to define how your app is structured. Content should adapt to the user to reduce cognitive load. They shouldn’t have to go looking for what they want, but be able to predict the route to and from their destination. See Cecilia Weckstrom’s talk for more.

Actual usage can change your product’s direction… For the better

We’ve all heard about YouTube originally being pitched as a dating site before morphing into what we see today. You might have designed your product to focus on a specific set of features, but how are your users actually using your product? Des Traynor’s (@destraynor) talk on Product Strategy touched on this with the example of weather apps — why focus so much on meteorological gobbledygook when users’ motive for using the app is to decide what to wear? Make the most of analytics events and engage with your users on a regular basis and you might just be surprised at your findings.

2) Be ruthless with MVPs and prioritisation

It’s that old chestnut again — the MVP. It can be tricky to define a laser-focused MVP, and UX can end up being affected when scope is pushed to the limit.” (See our earlier blog on MVPs here). At Kotikan, we don’t simply execute a client’s brief. We ensure we have a full understanding of company strategy, stakeholders, users and platforms, challenging the status quo where appropriate to arrive at the best solution possible.


Good UX is not a separate project or story, it needs to run through everything you do.

When working with multiple stakeholders, it can be tricky to make a case for ensuring a great experience over adding numerous features which 0.01% of users will use. When scope is tight, don’t compromise on good UX, but consider it as part and parcel of each individual feature in the MVP. Stephen Anderson’s talk ‘Sweating the UX details’ gave some great pointers on how to educate others on this point, as did John Kolko (@jkolko) with his arguments on how providing deep and meaningful engagement can be higher priority than adding new features or improving sales (a similar video presentation is available here).

It’s not about requirements definition, it’s about problem definition.

We are always learning, which is why ‘requirements’ are never really final. It’s important to constantly question and remind yourself to take a step back and get back to basics. Keep coming back to the same ‘W’ questions, even if previously defined:
What is the user trying to get done?
What’s the problem with how they currently do it? Is it really a problem they care about? Is it worth solving? CAN we solve it, and in which ways?
Why will they use our solution?
How do we know if we’ve solved users’ problem?
Is it worth us solving?

It’s not just what you ask, but who. When working with clients, it is important to establish ‘value propositions’. As Kim Goodwin highlighted: “We don’t have resources for that” really means “That value exchange is not reasonable enough for me”. Uncovering the hidden values of different stakeholders lets you understand what affects decision-making and where compromises can be made.

Should it stay or should it go?

It might be tough to kill that ‘baby’ you spent so long gestating, but feature creep can destroy user experience. Several speakers at UX London alluded to the usual analogy of the Swiss Army Knife (who needs a toothpick? I can’t even find a knife that can cut!). Focus more on improving current popular features and cutting those that aren’t being used. As Des Traynor proclaimed in his talk, either make users use it more, or make more users use it. Prevent getting to this stage of ‘feature bloat’ by ensuring you gauge needs, test prototypes with users and iterate regularly before launching.

3) Use Story Mapping to balance the big picture with important detail

We particularly enjoyed Jeff Patton’s (@jeffpatton) practical guide on story mapping and using stories as they were intended. We’ve found this method to be of great help in Kotikan’s projects and it has helped us ensure we follow agile methods the way they were designed.


Where do I start?

Story mapping is a collaborative and living process which organises stories into a visual, modifiable board displaying the activities users will do, the steps inside that activity, and the details of those steps. This can help you when you are faced with defining a new product without really knowing where to start. Build a Story Map collaboratively by literally talking through the ideal path a user will take to reach critical points in the product and ‘externalise’ what’s in everyone’s brain.

Backlog flatlog

Maintaining a backlog of stories can often result in a very flat way of seeing what’s next; turning into a pile of disconnected stories and making the team lose sight of the overall goal. Having a physical, visible story map can help you consider both the big picture and important details together. It also helps the team stay focused on the overall goal at all times.

Stories are just that — stories

Jeff reminds us that user stories were originally intended to be not simply written ‘requirements definitions’ representing work to be done, but rather a trigger for conversation. The act of mapping stories encourages collaboration across functions as different departments come together and describe what they will do to make the product come to life. This means that everyone learns together and stays ‘on the same page’ rather than individually reading documentation which becomes out of date in no time. This is of course one of the main pillars of Agile.

What do you think of the points above? Have you experienced any of these techniques before? Let me know using the comments board below.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.