Last week I gave a talk at the SAUX Cape Town meet-up at 22Seven’s vintage theatre, sponsored by Flow, 22Seven and BSG. The evening was something out of a fantasy: from a popcorn machine that greeted you at the door leading into a moody red-seated theatre with big giant pencils and ink pots completing the scene.
I shared the stage with the talented Sarah Blake who showed us the work she did on Woolworth’s responsive-designed site.
In this post I’ll share the details of my talk. You can download my slides from Speakerdeck.
Taking your dev team on the UX journey.
As a UI/UX designer at BSG, I typically work on designing internal software solutions for corporate companies, which comes with some challenges. One of these challenges is ensuring that your developers understand the user experience implications of the code they are introducing into a system that will ultimately be used by a person.
On a recent project that BSG undertook in the retail industry, I worked with our talented .Net team. I was only going to be on the project for a limited period of time whereas the developers would continue coding for months afterwards, so I knew I had to come up with a way for them to share the empathy I would have with our users.
Here are the techniques that I came up with which proved useful.
Usability heuristics are basically a set of best practice and guidelines, created by Jakob Nielsen, that, when followed while designing user interfaces, promises to deliver something that is user-friendly and easy to use.
What do Jakob Nielsen and Scrum have to do with each other?
Well…at BSG we mainly follow Scrum as our development methodology. In my talk I touch on some of the basic components at an extremely high level.
There is a backlog containing stories (big list of requirements). From this list the development team selects a subset of stories that they can deliver in a two-week cycle, called a sprint. Each story is some part of functionality that needs to be developed…these stories contain a definition of done – a list of stuff the developer writing the code needs to check before he can say he has completed that piece of code. It is here where I saw an opportunity to include our list of 10 usability heuristics as a constant reminder to the development team of what makes usable software.
It’s important to note that the definition of done that contains this list of heuristics gets reflected by the team on multiple instances throughout a sprint in the sprint planning session (breaking up the stories in to chunks of work), sprint reviews and sometimes in the retrospective.
As part of the Scrum process, there’s a daily stand-up where we go around saying what we did the day before, what we are working on today and what is in our way of getting things done. Next to the area where we held our stand-up I used a big white board with all the heuristics written down in big bold letters, which reinforced these to the team.
The second, just as important part of the project, was to have a set of design principles that the team could follow. These principles should be aligned to the project’s goals or business objectives and they can serve as beacons to the dev team when they need to make certain decisions that would impact the user when you are not present.
I wrote down our design principles next to the list of heuristics on the whiteboard for the whole team to see, slowly reinforcing these into their daily routine.
Here are the beacons we used on our project:
- Simple and intuitive
- Generate insights from historical data
- Stricter controls
Remember to try keep the number of principles to a minimum of about three.
Observe & analyse
This technique seems so obvious, yet it is overlooked. As UXers we are good at observing users and analysing their behaviour…so…
Observe and analyse your development team, as it will provide you with insights in terms of how they work and what works for them. A simple example of this may be the way you present your user data to them.
As the UX designer on our project I was in a central position in the team as I got to work with the clients, business analysts, project manager, developers, and most importantly, the users. I was able to observe from many different angles what was going on and use the insights to deliver my findings in a more effective way.
Remember…users don’t read. That same behavior happens when sending people pages of user data reports, so try to tell a story with your data to drive your points and observations.
“It doesn’t exist if it’s only in your head or on your computer.”
I can’t recall who said that, but the idea is clear and simple. Make sure that you share whatever information, results or insights with your team. Make sure what you share is visible, not just within the threads of emails. At one stage our workstation looked like a kinder garden class with all the pages I spread out on the walls and writing on the whiteboards.
Not only did I use the whiteboard to list our heuristics and design principles, but also created little printouts of examples of those heuristics in our system and stuck them onto the walls as well as the design principles. I also kept the data of the personas as sticky notes in an affinity diagram stuck onto a big sheet of paper that hung next to the whiteboard – everywhere you looked there was some user data lingering about.
This was my way of making the user present in our team.
Apart from the results and insights one learns about at usability tests, for me the two most important aspect of it is the empathy it creates for your users and to see first-hand how people actually react and interact with your solutions.
When it got to usability testing I made sure to take one developer along to the test just to sit there and observe, they didn’t have to do anything other than just witness what people actually did.
This is such a simple thing to do and the pay off is a development team that deeply cares about the impact their choices have on the users.
Design standards document
The final piece of the puzzle in my strategy to get our development team on the UX journey was to create a design standards document.
Not only is this a good artifact to have on hand as a whole for your project that promotes consistency, but it leaves behind a blueprint and kind of an instruction guideline to the team that can be used during implementation.
I created the document with the dev team in mind to ensure that it translated well into their world and what they were doing – in this case very HTML / CSS heavy. I also included actual font specimens, colour pallets and a grid that showed when to use what UI components such as buttons and messages.
Another benefit of this type of document is that it creates the online IP for your brand if you don’t have one and helps new team members quickly get on board with how to implement the design.
Most of the techniques above were part of on-the-ground coaching, but keep in mind that everything you do can be used as a piece of coaching.
Be that guy who keeps repeating himself every day. Remember those general knowledge facts on the Chappies wrappers?
Become the Chappies wrapper; be a walking encyclopaedia and know your research; explain your design choices; over-share; mention the user; repeat.
So, there you have it, that’s how I tried to get our development team to understand the users better and make sure they look after them. At the end, on our project it turned out to have been successful.
So to summarise here are the key aspects where you can get the dev team involved:
- Design principles
- Observe & analyse
- Usability testing
- Design standards document
Be authentic, love what you do and be passionate about doing it.
The BSG way
BSG values design thinking as a strategy in the various methodologies we use in solving problems for organisations. We constantly challenge the way we do things with applying the principles of lean startup, user experience design, agile, and design thinking in ways that ultimately allow us to do things differently from other business consulting companies.
Photos from the event
Please let me know if you have any questions on my techniques here or if you would like to hear the talk somewhere else.