Getting started: The engagement plan
When I joined this project, the team was already moving fast. My first job was to figure out how I could help without slowing them down while simultaneously building and executing a user engagement plan and conducting an audit of the work that had been done prior to my engagement.
The user engagement plan would show how we would talk to customers and test our ideas. This helped the engineering team see that design was there to help them win.
-
→
Recruit and Engage Lighthouse Customers: Lighthouse customers are key customers, who are identified with the assistance of product management, that will commit to giving us regular feedback and testing the feature during the development process.
-
→
Create a Private Slack Channel: To facilitate easy, frequent communication with the lighthouse customers, I created a private slack channel which included those customers and some key internal stakeholders.
-
→
Develop, Distribute, and Analyze Surveys: I developed, distributed, and analyzed the results from surveys on multiple platforms. For sensitive information, I used our Beta Forum as those users were already under NDA. For broader reach on topics that weren't as sensitive, I leverage our public forums and Qualtrics.
-
→
Discussion Facilitation: I engaged users on our beta forums by starting and participating in conversations related to the project.
-
→
Hands-On Testing: I developed a plan which included data sets and tutorials to engage users in hands-on testing. I worked with stakeholders to ensure all areas they wanted to see feedback on would be covered.
Knowing the team: Stakeholder mapping
I built a stakeholder map to keep track of everyone involved. It helped us understand who needed to see our progress and who could help us make the big decisions.
Catching up: The Heuristic Audit
Since the project had been running for six months without a designer, I started with a full audit of the work they had done so far. The following are just a few of the items that I identified:
Issue 1: Cognitive Load
The original settings interface would be overwhelming to engineers with too many options. I simplified the view to focus only on the information required for users to achieve their desired results.
Cluttered interface with irrelevant data points.
Streamlined view focusing on only what is relevant.
Issue 2: Lack of Transparency
There was no indication as to how many sheets the "automatic" option would generate. We exposed the sheet count in the UI to promote transparency and to help set the users expectations for what would be created. This was one of several places where transparency was needed for this project.
Issue 3: Inaccurate Results
I found that the drawings generated were missing critical dimensions. Upon further investigation, we found that the missing dimensions were due to a limit on the number of dimensions that would be generated. We consulted with customers and adjusted the default limit as well as exposed this so it could be adjusted if ever encountered in the future.
The solution: High Fidelity Prototyping
I built an interactive prototype to show how the automation engine would feel. This allowed us to test our ideas before more time went into development.
What our users said
"That's really awesome news; we were waiting for something like this for a long time. Great job to all of you!"
"I am irrationally excited for this. Already installed and started to play with it! Way to go team!"
"Hey there, I did a little test run on the features. The thing looks quite promising!"
"I can't wait! This is FANTABULOUS features!!"
The feedback was overwhelmingly positive, engineers were excited because we were solving real problems they faced every day. During the limited hands-on time we were able to provide for this project, there were some key things mentioned by the customers:
-
→
Customers encountered designs where they were not fully documented (there were sheets missing that they expected).
-
→
Customers voiced concerns about performance.
-
→
Customers requested to pre-select their dimension recipes based upon sheet type ahead of generation.
One year later: The impact
2D drawings generated containing:
Sheets created
Views created
Dimensions applied
Hurdles we cleared along the way
Building a tool this complex is never a straight line. These were some of the biggest challenges we had to navigate to get the project across the finish line.
-
→
Technical Debt
We had to build on top of an older system that was not originally designed for this kind of automation. This required creative problem solving to keep the interface fast and reliable.
-
→
Team Alignment
Joining a project six months in meant I had to quickly build trust with an engineering team used to working without a designer. I focused on showing them how UX could help them reach their goals faster.
-
→
Complex Rules
Technical drawings have very strict legal and safety requirements. We had to make sure our automation never skipped a critical check while still making the process feel easy for the user.
-
→
Leadership vs. Customer Expectations
There was a mismatch in what leadership wanted us to deliver and what the customers were ready for.
Final thoughts
This project taught me a lot about leading from within a team that was already moving fast. I learned that even when you join late, good design can still make a massive difference.
While the results show that people are using the new tools, I know that command usage doesn't always mean a customer is happy. We have since started a new initiative to measure actual satisfaction, but to truly understand the full life of a document, we still need to make deeper changes to how the software is built.
Bridging the trust gap
The biggest hurdle was a gap between what the business wanted to build and what the customers were actually ready for. My research showed that users didn't trust the automation to do the job perfectly yet. They weren't ready for a "black box" solution.
I worked with the product manager on a plan to roll the features out in stages. The goal was to build trust by showing users how the individual automations worked before giving them a single, push button solution.
When I presented this to the stakeholders, there were a lot of different opinions. In the end, the leadership decided to stick with the original plan. We took a "disagree and commit" approach, and I focused on helping the team deliver the first version to our customers on time. It was a great reminder that my role is to provide the evidence and a clear path forward, even if the final decision goes in a different direction.