But let’s back up a bit, I want to describe one of the key learnings for me as a product manager before I talk more about what we achieved.
How We Started
We started with neither UX researchers nor product designers to help us get there. I had worked with designers before to create websites, mostly graphic designers who had moved into the digital space. We decided this wasn’t a problem, our devs just rolled up their sleeves and got designing!
When you build software products, you expect the first iteration to have some bugs, often you don’t ship it for exactly that reason, you work on it to remove the bugs — to learn more about how it works and what is needed for it to run smoothly. You can express this as a chart by looking at variations from correct functioning over time.
This is the understanding we brought to the work of designing new versions of our software, we expected that we would start with a slightly wonky design and refine it into something amazing and tight. This is what our devs expected the process would be like.
So our devs launched into designing what we thought users would want. But whilst they were enthusiastic, they lacked some critical skills to be great at designing.
Drawing skills weren’t the real problem, nor was color sense, awareness of whitespace or a sense of style.
When I, as a product manager, saw the results I had to admit they were … interesting.
Actually, they were derivative, boring and pushed the boundaries in all the wrong directions.
But our real problem (other than not hiring designers) was the space we gave design in the development process.
There was one good thing, which was that after the CEO saw our initial results he approved hiring a UX Architect, then a Senior Designer and finally a bunch more design and UX people. But initially, we just had a single UX architect.
He worked out we were lacking a proper understanding of our users’ mental models (we had some theories, but no confirmation) and no clear picture of their work context to help us empathize with their needs. So he set about researching our user base, using contextual inquiry for the primary research method.
We had one more problem, we didn’t understand how to fit the needs of design into our typical software development process.
Learning Creativity
Around this time I came across a rather brilliant book Living with a Creative Mind from a married couple, one a musician and educator and the other a psychologist, who had worked together with many creative people and struggled with helping less creative people understand how to live with someone who has an intense creative process.
“A creative work begins with a perception i.e. a way of seeing something that is different from everyone else, or something that you have not seen before. What happens next is that perception evolves into discovery, an internalisation of the new seeing, where the filters of your life experience, knowledge, emotions and beliefs interact with the new thing. Finally something about this interpretation of the perception goes into production. That is when it is formed into something others can experience.”
Living with a Creative Mind
Jeff Crabtree & Julie Crabtree, 2011
In summary, you could picture this as a journey, from perception to discovery and then to production of a creative piece.
In our case, the UX research component was going to help us broaden our perceptive faculties and see more of the world our users lived in. If you are creative you might know this as a stage when you absorb like a sponge the world around you — gathering experiences and ideas like seashells.
The discovery phase was where you consider what you have learned and seen and derive meaning from it. It can be sudden and spontaneous, or a long laborious process itself. In the case of our design, it was going to take some time to understand what our research told us and to work through its impact on our design.
Production is all about creating, and again in some creative endeavors, it could be quick while in others it might take years. This is what we had already started doing and we realized we had skipped straight to it rather than giving ourselves time to perceive and discover truths.
It seems to work with our nice linear procession to a final design, right?
Wrong again.
“It is far more common for creativity to lack this kind of linear progression. Perception, discovery and production more frequently happen intuitively, non-sequentially, unconsciously and sometimes in a circular fashion, with one part of the process stimulating and affecting another in a feedback loop. Sometimes the phases occur almost simultaneously — intermingled with one each other.”
Living with a Creative Mind
Jeff Crabtree & Julie Crabtree, 2011
This meant our design process was still all over the place, more like a wild oscillation from one idea to another. At even the last moment we could discover fundamental truth that wildly changed our design.
That’s not a BAD thing, it’s actually GOOD design.
What we learned was design was not an exact art, it was a seeking of the right answer given our constraints, current knowledge and desired outcomes. It was complicated by the fact that we needed to start designing (and building) whilst our UX architect was still doing contextual research, which sometimes meant assumptions that were good might get challenged by his next lot of interviews.
“You know how our users all have two screens on their desks? Well, um, that wasn’t true in our Queensland customers — they mostly had a single 19” monitor to work with.”
The problem became that while we loved variation from a design viewpoint — it represented truth-finding — it wasn’t helpful from a software building perspective. We started seeing more and more bugs appearing in our ‘shippable’ code. It still wasn’t working.
Confusion Reigns
Working as a Scrum shop we had design stories and build stories intermingled in each sprint. Devs would take whichever one they felt most comfortable doing, not everyone loved designing, but we encouraged everyone to give it a go. When doing design they would be setting up the work for next sprint’s build stories.
In the same sprint, they would be speculating and going through their own perception/discovery/production cycle while at the same time trying to cut code to deliver features based on designs they did last sprint (which they could now see issues with).
It was driving our devs slightly mad.
It took several fortnight-long sprints for this to become obvious. We still weren’t happy with the quality of our UX designs, while they had improved with regards to being more user-centered, they were still messy and now we had poor quality code being produced as well. At the same time, we had a Scrum team that was new and experienced pretty severe internal team issues.
Happily, We Worked It Out
The front-end dev team ended up imploding, with three team members leaving the company and others moving back to previous roles. We took stock of where we were at and made some changes before hiring a new front-end team.
We decided to explicitly separate design and build. Giving each room to breathe and their own space.
Next, we hired a senior designer, someone with a good working knowledge of UX, but the design chops to pull off a consistent, clean, stylish design that we were happy to have our brand on.
With the product manager, UX architect, and designer, we created a product design team responsible for feeding well thought out designs to the dev teams.
They started work on two things, cleaning up the inconsistencies in the current design, and at the same time a new design language that would inform all of our designs going forward, with an emphasis on mobile-first experiences.
The product design team also worked on bringing our process more in line with the Nielsen Norman Group’s guidance around Design Thinking. We noticed that it mapped roughly to what we learned from Living with a Creative Mind which was confirmation we were onto a good thing.
Finally, the product design team implemented a recruitment program to start bringing in a regular stream of users for UX research to ensure we kept our knowledge up to date and kept expanding our perceptions of user needs. With enterprise software, particularly serving government customers, recruitment is tough because you can’t usually offer incentives. However, we had plenty of users that wanted to help us make the software better and we encouraged customers to promote this with their users.
The front-end dev team was re-formed, this time with experienced specialists who had worked with product design teams before. They focused on removing the bugs from the current code and implementing the design changes. Along the way, they decided to change the JavaScript framework used to something that would help them code faster and more productively.
With a clear focus on building a well-designed solution, they increased their velocity and the quality of their work. We made user research easily available to them and involved them as silent spectators when appropriate during user interviews and user testing. This helped increase their understanding of user problems without making them (alone) responsible for designing solutions to them. Team morale shot up as they started to see feedback about how good their solution a) looked and b) tested with end-users.
The result was a much-improved solution that we impressed the CEO with, the rollout of the design language across ALL products in the organization and delivery of user-centered software that was a huge hit with our end-users and thus their employers.
It was truly a UX revolution that changed every aspect of how we built software and is still paying dividends today.
Key Learnings
The key learnings for us were:
1. Don’t try to get the same people to design and build at the same time.
2. Respect the differences in the meaning of variation between design and build work.
3. Putting UX first makes users happy, makes their bosses happy, makes our bosses happy.