Some thoughts on UX Australia

I got to go to UX Australia this year, and it was a pretty interesting conference. Very much a conference for designers, though, as opposed to something like Webstock.

This originally appeared on our company blog, but I'm quite proud of this one so I'm keeping it here too.

~

The first thing that struck me about UX Australia was how friendly and inclusive everyone was. UX people are nice – I think I talked to more people in two days than I had done at all the previous conferences I’ve attended, combined. The other thing that struck me was how many people had used our tools, or at least heard of us. Due to where we’re located, it can sometimes feel like our users are just a mysterious bunch of people on the other side of the world. Being able to chat face-to-face with people who use our tools was a really validating experience.

For me, there were a couple key themes from the conference:

  1. Designing and testing user interfaces for mobile devices is a hot topic, and is only going to get more important as smartphones become more pervasive. This is very timely for us, as we’re in the process of doing just that – developing mobile-specific interfaces for our tools.
  2. Design teams need to collaborate with other teams to be effective. It’s clear that people think it’s important to give other parts of the project a sense of ownership and commitment – thereby cementing the importance of a good user experience.

One of the highlight presentations for me was a lightning talk from Mia Northrop revealing the contrast between the top 10 skills UX designers thought were important to their role, and the skills that other groups (Developers, Project Managers, etc.) thought were important to UX Designers. It had a clear important message:

It’s not enough to be aware of the skills that are important to your discipline, or that you value in others – you must also recognise the skills that other people value in you in order to work effectively as part of a team.

However, the most powerful insight as a developer attending a UX conference is the general undertone of antagonism towards developers. Perhaps I was overly sensitive to certain comments, but I couldn’t help but notice developers were often stereotyped as ignorant, or even malicious, when it came to design. This kind of thinking erodes the crucial trust required for these two groups to collaborate and work effectively together.

I’m not saying developers are blameless. They certainly aren’t. But I can’t see how designers can hope to encourage collaboration and a sense of ownership across the different parts of a project, or be effective advocates of design, if they don’t trust and respect the developers they’re working with. It creates an unnecessary “us” and “them” mentality, which is counter-productive when we’re all trying to evolve our processes past the clearly disfunctional ‘Big Design Up Front’ model of software development and towards the promised utopia of ‘Agile’.

One of the suggestions that came out of the conference was that Developers should to be “taught design”, to make up for the fact that designers can’t necessarily react to the design problems that crop up during development. This seems to mirror recent sentiment from the development community that “Everyone should learn to code“.

I don’t think that this is the solution. It seems like it’s treating the symptoms, not the disease. In both cases, it’s a quest for understanding. Both designers and developers want their contribution to be valued, and not just be thought of as wireframe factories or code monkeys. I think that in the same way that it’s important that we learn what skills we value in ourselves, and what others value in us, both sides of this argument need to be able to speak each other’s language - not learn how to do each others jobs.

A designer doesn’t need to be taught how to code, or how to use your MVC framework. But they should understand how that framework might affect the interaction, and how the developers are going to use conditionals and loops to implement the logic implied by their designs, and what this means for the structure of the design artefacts they put together.

To the average developer, the fact that two dropdown menus are different shapes, or different colours, or don’t adhere to the same grid is irrelevant as long as the menus themselves aren’t broken and that they are functionally the same. It doesn’t take a two week design course to teach them that it’s just as important to the user experience that they look the same; it just takes communication.