by Rebecca Richkus on September 24, 2009
Last year, I was fortunate to be part of a design collaboration for a major feature in AutoCAD MEP. I was the Interaction Designer, and Gregg Stanley, a Quality Assurance Analyst and a Subject Matter Expert (SME) on mechanical piping design (the feature theme), was to work with me to provide feedback and to help document the design. Our collaboration resulted in a great feature for the product, and provided a concrete example of how involving others in the design process equates to a better overall design. I decided to submit a proposal to the Usability Professionals’ Association (UPA) 2009 conference, with the idea that our collaboration experience would educate and benefit others.
Gregg was an SME on piping and on our software, but knew little about user-centered design processes. Certainly he’d seen our design documents, and was aware of the value of usability testing. But as a QA Analyst, he hadn’t been involved in early design work. Meanwhile, I had typically done requirements analysis and conceptual design without much input from anyone outside the User Experience group. We both found the experience of working together valuable and rewarding. But as we brainstormed ways to present about our collaboration, I became aware of the impact of our work together, particularly on Gregg’s view of the design process.
As we drafted our UPA proposal, we each wrote our version of “What happened during the project and what did you learn from it,” and then passed it to the other. When we compared notes, I realized that Gregg didn’t understand what the heck I was doing at the beginning of our project. He mentioned being frustrated, not knowing why I was so often asking “Why? How? How often? When?” about user scenarios he had identified. He also couldn’t understand why I wanted to keep generating solution ideas. Wasn’t one enough? While we worked very well through those process phases, the why of it all was mystifying to him. As the presentation progressed, I became fascinated with how he went from frustration to being able to speak authoritatively about our process to others. By the end, he understood that generating many solutions helps identify the best one. He knew that early focus on the abstract requirements helps to ensure that the solution is more holistic, rather than a patchwork of fixes. He also appreciated how the use of personas helps to focus questions. Our persona, Paula, began to more concretely represent a real, typical user, with specific design needs different than those Gregg had envisioned.
I often hear from other Design and Usability practitioners that their counterparts in other functional groups, particularly development, think that designers simply write specifications. We in the design field understand that the documents we produce are a result of the analysis and design work we’ve done (or possibly a tool to help us progress in a design). But it’s not always clear to others how or why we got to a documented solution. So I wondered, “At what point did Gregg grasp the design process? And how can we, in the UX group, help that happen for others in our organization?”
To answer that, Gregg and I worked to identify the process that unfolded from our collaboration, which included not only the steps in the design process but also the forming of a working relationship. Both aspects helped him understand where I was coming from.
The two main drivers for a successful relationship were to respect each other’s opinion and to use active listening to understand what the other was saying. Gregg had many detailed solution ideas at the beginning of our project. At that point, I didn’t want to decide on a solution, but wanted to understand what problem he saw and why he felt those solutions were important. By actively listening, I often learned of a new requirement or a flaw in the current product that had eluded me, and Gregg felt his opinion was heard and valued (and it was!). We took those good ideas and wrote them down so that they weren’t lost, and both Gregg and I could then move on to thinking of other possible solutions. Many times we came back and used the initial ideas, but for the times we didn’t use Gregg’s idea, this process allowed him to understand why a different solution was needed.
The second area of success was having Gregg involved from the beginning. In prior projects, other team members came onboard only after the requirements analysis work was mostly complete or when conceptual design work was far along. My teams would often help in finalizing designs without a full appreciation of the users’ problems we were trying to solve. In this case, the fact that Gregg helped write the Requirements Analysis document—and I helped him understand the separation of user requirements (what users need to be able to do with the software) from more specific design requirements (how our software will do something)—meant he and I were focused on the correct problems. Our vision of what the overall solution would be came from a shared understanding of the requirements, and we returned to this vision repeatedly as we generated conceptual design ideas and created the detailed design documents.
This experience highlighted for me that relationship-building and involvement in all parts of the design process are key factors when educating team members as to what user experience and design are about. In turn, these feature teams can create even better designs, and the team members involved will pass on this new knowledge in their next project, hopefully adding to better designs in the future. So grab your neighbor developer, QA analyst, or writer and sign them up to start working on a design with you!
Have you already had a similar experience? What tips can you share for those attempting to gain more buy-in and involvement from other functional groups?