From Product Trainer to Product Owner: Craig J Willis's Story
Our latest Champion is Craig J Willis. Craig is a long-time Mockups user who has used it in both enterprise and, now, startup environments. He wrote to us to tell us one of his Mockups success stories that resulted in him taking a big leap and scoring some major UX victories within his previous company.
After Craig told me his story, I thought it would be useful to share since it demonstrates how he was able to transform a development culture by focusing on the user experience and designing around it. His story also highlights that people most often suited to fix something are those who use it every day, which frequently aren't the developers or "owners" of the product.
But it is also a bit of a cautionary tale, exposing conflicts between ideals and realities of shipping commercial software (especially enterprise software) and explaining why User Experience can still be a tough sell in some organizations.
Seeing usability problems first-hand
Craig was on the education team for an enterprise software product with a large company. His job was to train customers on how to use the product. He knew how powerful and genuinely useful it was, but also knew that new features were continuously being added while the number of requests was growing daily. It was becoming increasingly difficult to consider the impact of every change. Something had to give.
All of the effort was being put into the business logic and very little into how everyday users might actually use it. This meant that all of its idiosyncrasies and faults became magnified every time a new feature was added. Craig said that in the focus to satisfy every customer request there just wasn't enough thought about the future of the product among the development team, they just kept adding on while making sure that everything still worked. "There were a lot of stop‑gaps."
That's not to say that the team was clueless or mis-guided. It can be hard to know about a product's usability problems without using it regularly, yet involving customers in the process can also be troublesome. Customers have a hard time imagining a different way for the product to behave, so they are more apt to ask for features rather than workflow improvements. But having the input of someone who teaches it to others can be very useful. They have to explain how to do things with it over and over and can't help but think of ways that it could be improved. Craig was just that person.
Craig had become frustrated trying to explain to customers the convoluted workflows and work-arounds required to use the product, knowing that there was no satisfying explanation for it. He also thought about how much time and money was being wasted getting customers up-to-speed on what should have been intuitive actions. He frequently complained, but wasn't in the right position to have any influence.
One day he overheard some people from the product team talking about hiring a design firm to give it a design overhaul. He got very excited. As Craig told me "I made sure to get invited to that meeting." In the meeting he was amazed to hear them spending "lots of time talking about fonts and colors." He knew that a fresh coat of paint wasn't going to solve the usability problems he knew all-too-well. He told me "I was like 'guys, we've got a much bigger problem.'"
In the meeting, when he said that the product was hard to use, he didn't get very far. But when he showed how it could be made better, people immediately saw what was wrong with the current product. He used Balsamiq Mockups to redesign a few screens so that he could show them how the workflow could be improved. Much like Michael Bourque, Craig used Mockups to tell a story about his vision for the product. This approach was so successful, in fact, that he was asked to take charge of the product right then and there. Craig told me: "I showed them what I was talking about and they made me Product Manager."
Thrust into the spotlight
Craig's promotion to Product Manager cast him in a very different role. He was now responsible for seeing through all the changes he had been suggesting. He learned how difficult it would be to put his obese product on a life-changing diet.
He began by saying no to a lot of feature requests, which didn't make him very popular. He says "I became one of the most disliked people at the company. Previously we had accepted and queued up every request. 'No' wasn't a word the team was used to hearing, but now they had to hear it from me, frequently."
This wasn't the only change. Craig was using visual mockups to communicate the development plan, whereas in the past they had used giant specification documents containing only a few screen shots, so it took some effort to convert people to this leaner way of doing things.
He persisted. He extolled the virtues of User Experience Design by quoting Don Norman's "The Design of Everyday Things" in meetings and by educating people on the difference between aesthetics and User Experience. This slowly got him the approval to spend development time to improve the User Experience.
To get the redesign rolling, again he turned to Balsamiq Mockups. Craig told me that they created mockups for 70-80% of all the screens in the product, which was a lot. Using them, he reached out to the sales team to vet his ideas. He then involved the development team to assess the feasibility of his designs. This iterative approach helped bridge the gap between the teams who knew what customers were having problems with and the teams who knew what was achievable in the time they had.
While most people got very excited when talking over Mockups, from time to time he'd still get asked "why does this look like a sketch?" Craig had internalized all of the User Experience literature he had read and would respond by saying "don't think about what it looks like, look at what it's doing". Again and again, he went through this process until everyone was on the same page and they had "ironed out" the usability and technical tradeoffs associated with the new design.
In fits and starts, the product began to transform into a more usable product that fit its users mental models better, yielding major UI improvements. It was released earlier this year and has been very well received by customers. Here are some screenshots of one of the mockups and the corresponding final product:
Lessons learned, applied to a new endeavor
Armed with both his experience as a product trainer and product manager, Craig and a partner recently ventured out on their own to improve the experience of capturing requirements for Agile development teams. They are setting out to fill in some of the gaps they've seen over the years in tools designed to support Agile development. Their new product is called Skore. It is a visual tool that makes writing and creating Agile user stories quick and easy. It cuts out many of the steps and simplifies it to the point that stories can be created in real time during meetings and conversations. Learn more about it at the-skore.com.
Do you have a story to share about the awesome things you do with Balsamiq? Send an email to firstname.lastname@example.org with your stories or blog posts!