Creating a Team Experience

When helping to create and deliver software, the user experience (UX) is at the core of my daily activities. It helps guide my questioning and decision making while helping to identify the value a product will bring when it’s being used.

I recently had the opportunity to speak at UXNZ 2016 ( on the topic of applying the things I’ve learnt in UX to teams. I believe that the people behind the software, the creators, designers and analysts, are more interesting and more complex than what they produce.

“Great teams that are respectful to each other and work in a safe and supportive environment are more capable of building great things.”


Like most things, my story starts with the people. In UX, we use Personas to help create empathy and connect with who will be using our product. There is a trap that we can fall into when we start to classify people and that is the stereotype. In our workplaces, a lot of us have a title, something that helps others identify what our role is or what we are responsible for. When a group of people have the same title, it can be easy to assume that all of those people are alike. We assume that the people with the same title must all be the same because we can make sense of that. In short, it’s easier to think this way.

When we do this, comments like ‘Developers don’t like change’ or ‘Testers like breaking things’ or ‘Product Owners only care about deadlines’ start to be heard. This reinforces stereotypes and we lose the identity, skill and unique experience that the individuals in our teams bring. I don’t work with anyone called ‘Developer’ or ‘Tester’, there are people with names that do those types of activities and they should be recognised as the individuals they are. I like to think that addressing people by their titles is a way in which we distance ourselves from unkind remarks because we’re not frustrated with the person, we’re frustrated with the role that person plays. Unfortunately, in reality, the person being talked about can feel attacked, boxed in and restricted by their title or role. We give persona’s a name because it helps us to connect.


The creation of prototypes enables us to gather feedback without the need to be production ready. Having something we can interact with makes it easier to identify any usability gaps and helps develop a clearer understanding of the vision for the product.

Words only ever give us part of the picture and words can conjure up different images for different people based on their own experience or knowledge in a particular area. If I ask you to think of a vegetable, because that’s a broad category, it’s likely that we are both thinking of different vegetables. While your mental prototype might produce a carrot, mine could produce a cucumber because that was something I encountered earlier in the day. We are both thinking of a vegetable and are both technically correct but we have still failed to have a shared understanding of the same vegetable.

Being explicit in our communication by using pictures as well as clarifying words, a shared understanding is easier to reach.

When we are being implicit, gaps and ambiguity can creep in. We tend to jump to our own conclusions and understanding based on many of our own biases and beliefs that we hold. If unsure about the shared understanding of a word or idea, don’t be shy to ask ‘What does that mean to you?’.

Measuring Success

In more recent times, improvements through iterations has become critical to a product’s success. Many companies have the ability to release code to production ‘when ready’ and users can have immediate access to those updates. When we first start to measure success, there are a lot of unknowns and sometimes a few nasty surprises when we find out we’re not doing quite as well as we thought we were. The natural reaction to something we don’t want to see is to make it go away. I call this the ‘box factor’. When opening a present on christmas morning we are usually either pleased because the gift in the box meets our expectations or we are disappointed because it doesn’t. One of these gifts will be opened while the other will probably remain in the closed box, left to gather dust.

When measuring success, it’s important to be transparent and accepting of both favourable and unfavourable possibilities.

At all times we expect the outcome to indicate either success or that there is still some more work to be done, that improvements are required. This approach means that there are no nasty surprises hiding in the box because we have been transparent about the possible outcomes. Reducing the impact of the surprise of an unfavourable outcome allows us to respond from a more measured and less reactive place.


Underpinning everything we do should be empathy, an understanding for our fellow humans. Empathy is the ability to connect with another person by understanding their point of view and recognising emotional responses. During my time in product development, I’ve picked up on three regularly said anti-empathic statements:

“At least they can…”

“There’s a workaround for…”

“Don’t worry, it’s just an edge case”

Hearing any of these in a review or product meeting immediately raises red flags for me and makes me re look at the solution in front of us. It’s a great indicator that there is still more work to be done. These statements show that we have failed to understand not only our customer and their user goals, but also that throughout development, the team has failed to communicate or understand a shared vision. Creating gaps in the product gives users the space to become frustrated or to experience an unhandled error. We have failed to map out their entire journey and have left metaphorical rivers and no bridge to cross them with.

By finding new ways to connect with the people around us in our work places, we can help create environments that foster innovation and products people love to build and use.