Morgan Keys

Autodesk ID

Background

Autodesk acquired BuildingConnected with the goal of building an end-to-end SAAS platform for the commercial construction process. Already strong in the design space with tools such as Revit and AutoCAD, BuildingConnected and other acquired products could bring data and workflow management solutions that would rival competitors like ProCore.

But the first step in this long-term vision was integrating user accounts. In the Fall of 2019, I was asked to lead an initiative to evaluate how BuildingConnected might integrate with Autodesk’s authentication platform, known as Autodesk ID.

Research initiative

I was assigned a team of designers, a Product Manager, a Researcher, and an Engineer. I created a project plan and planned multiple design workshops. In consultation with a Sr. Software Architect, I also identified 3 implementation options that would help frame our research:

“Linked Accounts”

Users would link an Autodesk account and manage it in their settings.

“Twin Credentials”

Users could choose which authentication method they preferred, saving steps if the are already logged in.

“One Account”

At some point users would create/link an Autodesk account and that would replace their BuildingConnected account.

We knew that something like One Account best resembled the long-term goal of a completely unified Autodesk platform, but it was not clear whether this would be the best experience for our users in the near term. We had differently branded products on different URLs and the inertia of users who were comfortable with their existing workflows. The question was: how might we introduce Autodesk in the most frictionless way possible?

As a team, we developed three rounds of prototype-testing, exploring the different implementations and interviewing users about their experience logging into other platforms. We tested with both internal users (sales, customer success) and external participants (via usertesting.com).

Example of a paper-prototype screen. We mirrored a critical BuildingConnected sign-up flow but used a fake service to reduce bias.

Insights

Over the course of protoyping and testing, some critical insights were uncovered:

Low general awareness of Autodesk and its products (other than AutoCAD)

Users unlikely to opt-in to Autodesk ID without a clear reason

Linked Accounts and Twin Credentials approaches could result in redundant experiences and would require ongoing management from the user

One Account could be inserted almost seamlessly into sign-up

Users were very open to adopting Autodesk if paired with a new feature

With these in mind, we decided to recommend the One Account implementation as a general approach. It would require us to build a potentially disruptive prompt asking users to adopt Autodesk, but it would also be a one-time experience.

Furthermore, BuildingConnected is a freemium, network-driven service. A quick and easy sign-up process is critical to network-quality and ultimately growth, revenue, and user value.

All of this made One Account a clear choice, not just strategically but also from a user experience perspective.

Recommending a roadmap

Toward the end of the research cycle, it occured to me that there was an opportunity to provide more than just guidance on the implementation method. Given that adoption was most likely when paired with yet-to-be-built features, and given that there were various sign-in and sign-up experiences that would need to be updated to support Autodesk ID, what we needed was a plan.

For our last synthesis workshop, I focused the team on forming guiding principles. From these principles, we formed a framework for the long-term transition. We recommended three phases: Pilot, Promote, and Migrate.

During the Pilot phase, we would introduce Autodesk ID to small groups (thorugh manual activation if necessary) in order to get initial reactions and learn more about workflows. This would allow us to design and test specific experiences, such as as sign-up and sign-in, as well as develop integrations—for example sharing data or files in key workflows. It would also allow us time to request technical fixes from the Autodesk ID engineering team.

The next phase, Promote, would involve introducing Autodesk ID as an optional add-on. We could incentivize users to adopt by offering high-value integrations and ultimately building trust and goodwill (as opposed to forcing adoption suddenly). This phase would continue until adoption met critical mass (based on percent-adopted).

The final phase, Migrate, was a recognition that there would likely always be a “long-tail” of users who would not adopt. At some point unification would become imperative and we would have to force users to migrate. The focus of the Migrate phase would be to design a one-time mandatory link experience, an email/notification campaign to ensure awareness of the coming deadline, and to build fall backs for long-dormant users.

The hope was that this sequence would maximize flexibility and minimize user frustration.

Diagram

Solution in detail: Sign-up via invitation-to-bid

The process of migrating users to Autodesk will require various integration-features and prompts throughout 2021 and into 2022, but for this case study I will focus on one particularly critical experience: new-user sign-up.

Scenario: Invitations to Bid

One of the most common and critical experiences for BuildingConnected is when a subcontractor receives an invitation to bid on a project.

General contractors are trying to find quality subcontractors to provide cost estimates and ultimately perform specific trade-work. They can use BuildingConnected to search for subcontractors, invite them to a project and analyze their proposals. In many cases though, particularly in new markets, they will need to invite subcontractors that are not yet on the network.

BuildingConnected allows general contractors to invite people via email address and then requires new sign-ups to register their company information, creating a re-enforcing cycle.

Thus, it is critical that the sign-up experience remain as friction-less as possible.

The pre-existing landing page

Subcontractors receive BuildingConnected invites via email. If interested, users follow a link to the invitation-to-bid landing page. This page features some basic information and a call-to-action to sign-up and view the invitation in more detail.

Pre-existing landing page for invitations-to-bid

This lander has been live since the early days of the company and while I don’t know the all the reasoning that went into it’s design, there are a few key choices we can speculate about:

Multiple references to the individual who sent the invite reflect long-running user-research insights about the importance of personal relationships

The single prominent email input field and “Create account” button are a progressive disclosure (clicking the button will prompt the user to also enter their full name and a password). This likely lowers activation-energy, slightly increasing the likelihood that users will decide to sign-up. There may also be a slight endowment effect in that users may feel they have already commited after this point.

The lack of a password input adds a natural step during which we can check the email address for several edge-cases

A complex set of use cases

While the primary goal of the lander is to encourage new users to engage and sign-up, several other cases need to be considered. Subcontractors have historically been difficult to engage and they may only use BuildingConnected occasionally. When they do visit, it’s important that the lander page take every opportunity to help them sign in with the correct account and avoid network-polluting duplicate profiles.

Thus, the page must seamlessly handle:

New users who have never signed-up

Users who have signed-up in the past

Users who have signed up and whose company pay for custom authentication (“SSO”)

Autodesk authentication

In order to implement the One Account experience, I needed to design a way to insert Autodesk ID into the invitation-to-bid. Autodesk ID is a standardized experience, which comes with pros and cons. On one hand, there is no need to redesign the core authentication flows. On the other hand, there are intentionally few customization options and it is effectively a black box from the perspective of our application.

Ultimately, there is a fragmentation and we must add the following use cases to our lander:

New users who have never signed-up for either BuildingConnected or Autodesk

New users who have never signed-up for BuildingConnected but already have Autodesk ID

Users who have signed-up for BuildingConnected in the past but may or may not have Autodesk ID

Architecture of the One Account implementation

The challenge of supporting legacy authentication

Updated lander

Handling these new use cases without disrupting such a critical workflow required fairly surgical design interventions. (And this is not to mention limited resources and the political senstivity of the page). I designed a few simple changes to the landing page with two primary goals in mind.

First, I wanted to subtly introduce Autodesk branding in order to communicate that there was a relationship between Autodesk and BuildingConnected. After this page, users would be redirected to an Autodesk sign-up/sign-in page—if users did not have some level of awareness of Autodesk, the experience could be confusing and mysterious.

Second, I wanted to make sure that returning users could still understand how to sign in. Technically, we could check the entered email and always redirdect users to the right place. But that would not be immediately obvious at first glance. We needed to give users “escape hatches” to get out of the sign-up flow and enter a more standard sign-in flow.

Here is the updated page:

Updated invitation-to-bid lander

Branded sign-in button, foreshadows redirect to Autodesk

Instead of “Already have an account”, which is technically ambiguous, use the more direct “I’ve used BuildingConnected before”

Simplified, goal oriented call-to-action: “...to view this RFP and download files”

“Autodesk company” co-branding in header

A “panic” sign-in button in header. For users who might be confused or miss the secondary button

Designing for every scenario

To solve for the many scenarios, I took advantage of an existing two-step credential input pattern. BuildingConnected historically used this pattern to handle users who paid for custom authentication (“SSO”)—instead of taking a password from these users, the system redirects them to an Identity Provider (“IDP”) hosted by their company. This private “IDP” would authenticate the user and redirect them back to BuildingConnected where they would be signed-in to the app. This is used both in the sign-in process but also in the sign-up process. In the latter case, the company’s IDP approves the user to be provisioned a new account. (This is also a fairly common pattern used in sites and services that support 3rd-party applications).

Functionally, this is very similar to how we needed to integrate Autodesk ID. The main difference is that instead of just checking for an existing account and whether or not the email domain is owned by a paying customer, we would now need to check the following additional cases:

New users: Is this user’s email already associated with an Autodesk ID?

Existing user: has the user already registered an Autodesk ID with their BuildingConnected account?

Is this user currently signed-in to their Autodesk ID?

In the first case, the user has used Autodesk before, but not BuildingConnected. We need to create a BuildingConnected account for them and then tie that account to their existing Autodesk ID.

In the second case, if an existing user tries to sign-in, it’s possible they may have already gone through the process of registering an Autodesk ID with their BuildingConnected account. This could happen through various in-app prompts that we exposed separately during the pilot period (and it would become more likely in the future as our base of Autodesk ID users grew). For these users, we would need to skip account-creation and send them to Autodesk sign-in.

In the third case, the user has Autodesk ID and is currently signed into Autodesk. For these users, there is no need to send them to an Autodesk sign-up or sign-in page. They are already authenticated, we simply need to create a BuildingConnect account for them or let them into the app.

Combining these consdierations with all scenarios, I designed the following overall experience flow:

Simplified flow-diagram for the invitation-to-bid sign-up experience

Here are all cases in more granular detail:

Diagram

All scenarios for signing-up from the invitation

Diagram

Subsection for the “SSO” option

Call-to-action labels

While the two-step credential inputs would technically catch all scenarios, there was more we could do to communicate to the user what was happening in the moment. I designed the following treatment to handle all scenarios.

Users with legacy accounts would see an unbranded sign-in button, existing users with Autodesk ID would be asked to sign-in, and all other users would be asked to sign-up for BuildingConnected using a new or existing Autodesk ID.

Diagram

Call-to-action labels change depending on scenario

Catching users with the wrong ID

Separately, while piloting the sign-in experience, we discovered an interesting edge case. Based on a technical implemenation detail, if users are currently signed-in to an Autodesk ID account and they trigger either a sign-in or sign-up flow, the system will skip past the Autodesk screens and take the user directly the app (or the welcome flow if it is a new user). Basically, the user is already authenticated, so the system does not ask them to sign-in again. (However, I did add a momentary “Redirecting to Autodesk...” interstitial to make the process more transparent).

Initially, this was viewed as a minor positive. Although we did not expect many users to have Autodesk ID or to be signed-in already, those who were signed-in could access BuildingConnected in a single, frictionless click.

But Autodesk ID is an interesting case. Autodesk ID is a single identity intended for all of Autodesk’s portoflio. Autodesk products include everything from highly controlled enterprise applications such as BIM 360, to individual contributor tools such as AutoCAD or Fusion 360, to hobbyist applications such as TinkerCAD. For enterprise applications, the user would need an Autodesk ID that uses their company email address, but for any hobbyist work, they might want to use a second, personal Autodesk ID. Yet another example would be users that had both a personal account and a team account, e.g. “estimators@company.com”.

Ultimately this meant that there was a small, but real, possibility that users might trigger one of our flows and suddenly find themselves logged in with an Autodesk ID that they did not want to use.

There are various ways to solve this problem. For example, Google’s authentication platform allows users to be signed in to muliple accounts at once and they can choose which identity they want to use for any given purpose. Unfortutnely, Autodesk ID does not support this use-case and it’s unclear if they ever would.

So to handle our edge case, I designed this simple confirmation page:

Call-to-action labels change depending on scenario

Key design choices:

“Card” design on the left encapsulates all information pulled from Autodesk ID, implying something being imported into BuildingConnected

Copy on the right comfirms that the user has now joined BuildingConnected and readies them for the standard welcome flow which asks them for profile information.

Subtle “Wrong ID” link allows edge-case users to back out without creating much distraction for our main-case users.

Current status

The sign-up experience is currently in development and is slated to be released for a trial period in March 2021. Autodesk ID integration is a central part of BuildingConnected’s 2021 and 2022 roadmap. The original research and project plan were presented in Fall 2019 and all subsequent work was done in 2020. According to internal feedback, while many in our division first found Autodesk integration to be daunting task, these projects and my on going efforts to promote Autodesk ID and share my knowledge have helped to make the process more tangible and approachable.

Morgan Keys | Winter 2021

Morgan Keys

Autodesk ID

Background

Autodesk acquired BuildingConnected with the goal of building an end-to-end SAAS platform for the commercial construction process. Already strong in the design space with tools such as Revit and AutoCAD, BuildingConnected and other acquired products could bring data and workflow management solutions that would rival competitors like ProCore.

But the first step in this long-term vision was integrating user accounts. In the Fall of 2019, I was asked to lead an initiative to evaluate how BuildingConnected might integrate with Autodesk’s authentication platform, known as Autodesk ID.

Research initiative

I was assigned a team of designers, a Product Manager, a Researcher, and an Engineer. I created a project plan and planned multiple design workshops. In consultation with a Sr. Software Architect, I also identified 3 implementation options that would help frame our research:

“Linked Accounts”

Users would link an Autodesk account and manage it in their settings.

“Twin Credentials”

Users could choose which authentication method they preferred, saving steps if the are already logged in.

“One Account”

At some point users would create/link an Autodesk account and that would replace their BuildingConnected account.

We knew that something like One Account best resembled the long-term goal of a completely unified Autodesk platform, but it was not clear whether this would be the best experience for our users in the near term. We had differently branded products on different URLs and the inertia of users who were comfortable with their existing workflows. The question was: how might we introduce Autodesk in the most frictionless way possible?

As a team, we developed three rounds of prototype-testing, exploring the different implementations and interviewing users about their experience logging into other platforms. We tested with both internal users (sales, customer success) and external participants (via usertesting.com).

Example of a paper-prototype screen. We mirrored a critical BuildingConnected sign-up flow but used a fake service to reduce bias.

Insights

Over the course of protoyping and testing, some critical insights were uncovered:

Low general awareness of Autodesk and its products (other than AutoCAD)

Users unlikely to opt-in to Autodesk ID without a clear reason

Linked Accounts and Twin Credentials approaches could result in redundant experiences and would require ongoing management from the user

One Account could be inserted almost seamlessly into sign-up

Users were very open to adopting Autodesk if paired with a new feature

With these in mind, we decided to recommend the One Account implementation as a general approach. It would require us to build a potentially disruptive prompt asking users to adopt Autodesk, but it would also be a one-time experience.

Furthermore, BuildingConnected is a freemium, network-driven service. A quick and easy sign-up process is critical to network-quality and ultimately growth, revenue, and user value.

All of this made One Account a clear choice, not just strategically but also from a user experience perspective.

Recommending a roadmap

Toward the end of the research cycle, it occured to me that there was an opportunity to provide more than just guidance on the implementation method. Given that adoption was most likely when paired with yet-to-be-built features, and given that there were various sign-in and sign-up experiences that would need to be updated to support Autodesk ID, what we needed was a plan.

For our last synthesis workshop, I focused the team on forming guiding principles. From these principles, we formed a framework for the long-term transition. We recommended three phases: Pilot, Promote, and Migrate.

During the Pilot phase, we would introduce Autodesk ID to small groups (thorugh manual activation if necessary) in order to get initial reactions and learn more about workflows. This would allow us to design and test specific experiences, such as as sign-up and sign-in, as well as develop integrations—for example sharing data or files in key workflows. It would also allow us time to request technical fixes from the Autodesk ID engineering team.

The next phase, Promote, would involve introducing Autodesk ID as an optional add-on. We could incentivize users to adopt by offering high-value integrations and ultimately building trust and goodwill (as opposed to forcing adoption suddenly). This phase would continue until adoption met critical mass (based on percent-adopted).

The final phase, Migrate, was a recognition that there would likely always be a “long-tail” of users who would not adopt. At some point unification would become imperative and we would have to force users to migrate. The focus of the Migrate phase would be to design a one-time mandatory link experience, an email/notification campaign to ensure awareness of the coming deadline, and to build fall backs for long-dormant users.

The hope was that this sequence would maximize flexibility and minimize user frustration.

Diagram

Solution in detail: Sign-up via invitation-to-bid

The process of migrating users to Autodesk will require various integration-features and prompts throughout 2021 and into 2022, but for this case study I will focus on one particularly critical experience: new-user sign-up.

Scenario: Invitations to Bid

One of the most common and critical experiences for BuildingConnected is when a subcontractor receives an invitation to bid on a project.

General contractors are trying to find quality subcontractors to provide cost estimates and ultimately perform specific trade-work. They can use BuildingConnected to search for subcontractors, invite them to a project and analyze their proposals. In many cases though, particularly in new markets, they will need to invite subcontractors that are not yet on the network.

BuildingConnected allows general contractors to invite people via email address and then requires new sign-ups to register their company information, creating a re-enforcing cycle.

Thus, it is critical that the sign-up experience remain as friction-less as possible.

The pre-existing landing page

Subcontractors receive BuildingConnected invites via email. If interested, users follow a link to the invitation-to-bid landing page. This page features some basic information and a call-to-action to sign-up and view the invitation in more detail.

Pre-existing landing page for invitations-to-bid

This lander has been live since the early days of the company and while I don’t know the all the reasoning that went into it’s design, there are a few key choices we can speculate about:

Multiple references to the individual who sent the invite reflect long-running user-research insights about the importance of personal relationships

The single prominent email input field and “Create account” button are a progressive disclosure (clicking the button will prompt the user to also enter their full name and a password). This likely lowers activation-energy, slightly increasing the likelihood that users will decide to sign-up. There may also be a slight endowment effect in that users may feel they have already commited after this point.

The lack of a password input adds a natural step during which we can check the email address for several edge-cases

A complex set of use cases

While the primary goal of the lander is to encourage new users to engage and sign-up, several other cases need to be considered. Subcontractors have historically been difficult to engage and they may only use BuildingConnected occasionally. When they do visit, it’s important that the lander page take every opportunity to help them sign in with the correct account and avoid network-polluting duplicate profiles.

Thus, the page must seamlessly handle:

New users who have never signed-up

Users who have signed-up in the past

Users who have signed up and whose company pay for custom authentication (“SSO”)

Autodesk authentication

In order to implement the One Account experience, I needed to design a way to insert Autodesk ID into the invitation-to-bid. Autodesk ID is a standardized experience, which comes with pros and cons. On one hand, there is no need to redesign the core authentication flows. On the other hand, there are intentionally few customization options and it is effectively a black box from the perspective of our application.

Ultimately, there is a fragmentation and we must add the following use cases to our lander:

New users who have never signed-up for either BuildingConnected or Autodesk

New users who have never signed-up for BuildingConnected but already have Autodesk ID

Users who have signed-up for BuildingConnected in the past but may or may not have Autodesk ID

Architecture of the One Account implementation

The challenge of supporting legacy authentication

Updated lander

Handling these new use cases without disrupting such a critical workflow required fairly surgical design interventions. (And this is not to mention limited resources and the political senstivity of the page). I designed a few simple changes to the landing page with two primary goals in mind.

First, I wanted to subtly introduce Autodesk branding in order to communicate that there was a relationship between Autodesk and BuildingConnected. After this page, users would be redirected to an Autodesk sign-up/sign-in page—if users did not have some level of awareness of Autodesk, the experience could be confusing and mysterious.

Second, I wanted to make sure that returning users could still understand how to sign in. Technically, we could check the entered email and always redirdect users to the right place. But that would not be immediately obvious at first glance. We needed to give users “escape hatches” to get out of the sign-up flow and enter a more standard sign-in flow.

Here is the updated page:

Updated invitation-to-bid lander

Branded sign-in button, foreshadows redirect to Autodesk

Instead of “Already have an account”, which is technically ambiguous, use the more direct “I’ve used BuildingConnected before”

Simplified, goal oriented call-to-action: “...to view this RFP and download files”

“Autodesk company” co-branding in header

A “panic” sign-in button in header. For users who might be confused or miss the secondary button

Designing for every scenario

To solve for the many scenarios, I took advantage of an existing two-step credential input pattern. BuildingConnected historically used this pattern to handle users who paid for custom authentication (“SSO”)—instead of taking a password from these users, the system redirects them to an Identity Provider (“IDP”) hosted by their company. This private “IDP” would authenticate the user and redirect them back to BuildingConnected where they would be signed-in to the app. This is used both in the sign-in process but also in the sign-up process. In the latter case, the company’s IDP approves the user to be provisioned a new account. (This is also a fairly common pattern used in sites and services that support 3rd-party applications).

Functionally, this is very similar to how we needed to integrate Autodesk ID. The main difference is that instead of just checking for an existing account and whether or not the email domain is owned by a paying customer, we would now need to check the following additional cases:

New users: Is this user’s email already associated with an Autodesk ID?

Existing user: has the user already registered an Autodesk ID with their BuildingConnected account?

Is this user currently signed-in to their Autodesk ID?

In the first case, the user has used Autodesk before, but not BuildingConnected. We need to create a BuildingConnected account for them and then tie that account to their existing Autodesk ID.

In the second case, if an existing user tries to sign-in, it’s possible they may have already gone through the process of registering an Autodesk ID with their BuildingConnected account. This could happen through various in-app prompts that we exposed separately during the pilot period (and it would become more likely in the future as our base of Autodesk ID users grew). For these users, we would need to skip account-creation and send them to Autodesk sign-in.

In the third case, the user has Autodesk ID and is currently signed into Autodesk. For these users, there is no need to send them to an Autodesk sign-up or sign-in page. They are already authenticated, we simply need to create a BuildingConnect account for them or let them into the app.

Combining these consdierations with all scenarios, I designed the following overall experience flow:

Simplified flow-diagram for the invitation-to-bid sign-up experience

Here are all cases in more granular detail:

Diagram

All scenarios for signing-up from the invitation

Diagram

Subsection for the “SSO” option

Call-to-action labels

While the two-step credential inputs would technically catch all scenarios, there was more we could do to communicate to the user what was happening in the moment. I designed the following treatment to handle all scenarios.

Users with legacy accounts would see an unbranded sign-in button, existing users with Autodesk ID would be asked to sign-in, and all other users would be asked to sign-up for BuildingConnected using a new or existing Autodesk ID.

Diagram

Call-to-action labels change depending on scenario

Catching users with the wrong ID

Separately, while piloting the sign-in experience, we discovered an interesting edge case. Based on a technical implemenation detail, if users are currently signed-in to an Autodesk ID account and they trigger either a sign-in or sign-up flow, the system will skip past the Autodesk screens and take the user directly the app (or the welcome flow if it is a new user). Basically, the user is already authenticated, so the system does not ask them to sign-in again. (However, I did add a momentary “Redirecting to Autodesk...” interstitial to make the process more transparent).

Initially, this was viewed as a minor positive. Although we did not expect many users to have Autodesk ID or to be signed-in already, those who were signed-in could access BuildingConnected in a single, frictionless click.

But Autodesk ID is an interesting case. Autodesk ID is a single identity intended for all of Autodesk’s portoflio. Autodesk products include everything from highly controlled enterprise applications such as BIM 360, to individual contributor tools such as AutoCAD or Fusion 360, to hobbyist applications such as TinkerCAD. For enterprise applications, the user would need an Autodesk ID that uses their company email address, but for any hobbyist work, they might want to use a second, personal Autodesk ID. Yet another example would be users that had both a personal account and a team account, e.g. “estimators@company.com”.

Ultimately this meant that there was a small, but real, possibility that users might trigger one of our flows and suddenly find themselves logged in with an Autodesk ID that they did not want to use.

There are various ways to solve this problem. For example, Google’s authentication platform allows users to be signed in to muliple accounts at once and they can choose which identity they want to use for any given purpose. Unfortutnely, Autodesk ID does not support this use-case and it’s unclear if they ever would.

So to handle our edge case, I designed this simple confirmation page:

Call-to-action labels change depending on scenario

Key design choices:

“Card” design on the left encapsulates all information pulled from Autodesk ID, implying something being imported into BuildingConnected

Copy on the right comfirms that the user has now joined BuildingConnected and readies them for the standard welcome flow which asks them for profile information.

Subtle “Wrong ID” link allows edge-case users to back out without creating much distraction for our main-case users.

Current status

The sign-up experience is currently in development and is slated to be released for a trial period in March 2021. Autodesk ID integration is a central part of BuildingConnected’s 2021 and 2022 roadmap. The original research and project plan were presented in Fall 2019 and all subsequent work was done in 2020. According to internal feedback, while many in our division first found Autodesk integration to be daunting task, these projects and my on going efforts to promote Autodesk ID and share my knowledge have helped to make the process more tangible and approachable.

Morgan Keys | Winter 2021