Autodesk acquired BuildingConnected in 2019. BuildingConnected focused on bid solicitation, serving both general contractors and subcontractors. By targeting the sending and receiving of requests for proposals, BuildingConnected grew organically into a large network of 1M+ construction companies, with a wealth of data on trades and pricing.

The two businesses ran on different models. BuildingConnected was a hybrid freemium product and a two-sided market: inviting off-network subcontractors led to organic growth and more value, and subcontractors and general contractors each owned their own data. Autodesk Construction Cloud primarily targeted larger enterprises, where general contractors provisioned accounts for their subcontractors and consultants and owned the data. Still, BuildingConnected fit well into a platform of point solutions, and it stood to benefit from Autodesk’s advanced tools and capabilities.

Stakeholders wanted us to “stress-test” these options. One Account seemed like a massive change, but the alternatives seemed like they could introduce complexity to the experience. They wanted the team to identify which options introduced the least “friction” to the user experience.

With this in mind, I planned three rounds of prototyping and testing to explore the impacts of different options. But we also needed the right test case. With a project as open-ended as this, we needed to not only define what solutions to test, but also what user flows were most important to test.

There were various user flows related to authentication, but in talking with the team, I urged them to focus on sign-up flows. I saw sign-up as critical for two reasons:

1. Sign-up flows are often a point of friction because they require various inputs and choices.
2. As a freemium, network-driven service, sign-up was critical to BuildingConnected’s growth and long-term success.

With the team in alignment, we set out to conduct user testing.

For Linked Accounts, we tested a hypothetical messaging service where users were invited to view messages but had to use a secondary service to access attachments. It felt frustrating and redundant, and it would be difficult to introduce during sign-up.

Twin Credentials used the same scenario with “twin” sign-up buttons. That removed the redundancy, but users saw no reason to use the secondary sign-up.

For One Account, we tried getting users to migrate mid-flow by offering a real value proposition to real users. A clear value meant less resistance and friction. We also learned that there was little awareness of Autodesk, and that email verification was tricky.

With Autodesk ID, we had to add more scenarios to this workflow. Authentication and sign-up would have to redirect through Autodesk for some users and BuildingConnected’s legacy systems for others. I created a matrix of scenarios, crossing whether someone had a BuildingConnected account with whether they had an Autodesk account. Users who already had both platforms would need to connect/merge their existing accounts, while other users would have to create an account and then find and sign-in with the other, existing account. Users who had neither would have to create everything at once.

We started with the “happy path”—the case where users were new to both platforms. If we could define an experience for new users that felt like a single unified flow, we could protect the platform’s growth potential and all other flows would be edge cases or temporary states until final migration.

With the happy path defined, I proceeded to map a flow diagram for how we would handle different user flows. Using a simple check on the input field, we could catch whether someone already had an Autodesk ID or a BuildingConnected ID and direct them as needed.

Incidentally, while mapping these flows, I identified a minor security vulnerability. Because we weren’t requiring users to verify their Autodesk account before accessing BuildingConnected, it would have been theoretically possible to “steal” someone’s BuildingConnected account. I proposed a solution and worked with a senior engineer to work out how to fix the issue.

There were many moving parts in this project and many little touch points. I could see that we needed a long-term plan. I came up with a multi-step plan for release and migration, and presented it to my team for feedback and buy-in. The plan had no dates. There was a lot of uncertainty around which future integrations we wanted to build and how users would react to the introduction of Autodesk, so I proposed a flexible timeline based on thresholds, not arbitrary dates.

Phase I, Groundwork, gave engineering time to build basic infrastructure and meet the technical requirements for integration. I used this phase to design the invitation and prompt flows while engineering implemented back-end infrastructure.

Phase II, Pilot, would manually enable Autodesk ID for friendly customers we knew would be open to migrating. We would test integration prototypes with them and monitor for friction and UX blockers. The goal would be to launch our MVP Autodesk integrations, in hope that we could use those to incentivize broader adoption.

Phase III, Promote, would actively encourage people to opt in, using our high-value integrations as the incentive, until adoption met an agreed-upon threshold (e.g. 80% of users).

Phase IV, Migrate, would set a deadline once the bulk of users had moved and there was enough value to justify disrupting the remaining users. That meant an email and communications plan, an in-app countdown, removing the ways to sign in with BuildingConnected, and flows to catch users who missed the deadline.