On the AutoCAD UX team, we've been thinking a lot about building trust with our customers.
We've recently transitioned our software development process from waterfall to Agile. As a result, we are getting closer to having smaller, working chunks of code that we can show to customers sooner.
We have designed a Customer Council program as a way to partner with customers throughout the development of our key features. AutoCAD has a very broad user base from nearly every industry. So for each Customer Council, we carefully select people who have a vested interest in a particular feature area, and invite them to participate in our development process with us. Through the council, participants get to preview very early builds of AutoCAD that have partially complete functionality, revealing the direction we're going. They can try the functionality out on their own drawings and projects, give feedback, and watch the features evolve. This gives customers much earlier exposure to the actual implemented solution. The big win for us is that we can get feedback in time to make really meaningful changes.
Often, with AutoCAD, you have to wait until everything comes together to get a good understanding of the experience that a user will have. Unlike a website, in which interactions are often linear and decoupled, the AutoCAD experience is an immersive design canvas with complex, highly-precise interactions, relying on a sophisticated graphics system. If performance is slow or the code isn't stable, it will drastically interfere with our users’ experience and we will lose the sense of how they would really behave. For example, with slow performance, you see cognitive step-down effects that cause users to lose their concentration and shift focus. In cognitively demanding tasks like design, this breaks our users' flow and dramatically changes how they work.
We've noticed that sharing these early bits of code with customers is like exposing your soft underbelly. You know the code isn't rock-solid, and there will be bugs and quirks and probably crashes. You can't hide the buggy areas with a well-practiced demo, or a controlled usability session. You are releasing the code over to customers to try out on their own, in the wild, to do whatever they might with it.
To do this, you have to be willing to be more vulnerable. This is where trust comes in. We don't want to let our customers down or to disappoint them. We're also aware that the first impression is crucial because it can anchor our users' perceptions and expectations in the future. These concerns are in direct conflict with the goal of letting users into the inner chambers of our design process, allowing them to co-design with us, and observe the work in progress as it comes together.
In spite of the discomfort of being exposed, we are learning to be more vulnerable. So far, we have found that many people are willing to work with us from this early stage. They are prepared to put up with the bugs and crashes in return for being able to help guide and influence the functionality so that it gives them what they need. And through this process we are building trust.
By partnering with our customers in a deeper way, we are building more human relationships. For example, we introduce the council participants to the relevant development team at Autodesk. We share names and pictures of people, have webinars and one-on-one phone calls. This helps us move beyond the perception of being the big company Autodesk, to just being people who are trying hard and doing our best, who will acknowledge if we make the wrong assumption about a feature or leave out something that is important.
We want to build something that users are thrilled to get their hands on and that will amplify their abilities to do even more amazing work. We are still in the early stages of learning with Customer Councils, but we are getting glimpses that we can get closer to our goal by letting users into the development process earlier.