Issue management is not standardized because the data capture is not uniform from the field
Contractors and subcontractors were using Autodesk Build for issue management under the promise of connected construction to power their projects with accurate from the ground. However, contractors were spending too much time triaging information from various sources or having to do back an forth to get the right data, without getting reliable information back from the field.
Our customers wanted to have a foolproof way of getting the data back from the field, without overburdening the field users to fill out more information than they need to. Customers had setup extensive reports via APIs and data connectors to get all the information they need from Issues. Without a foolproof way, they would not be able to adopt the Issues tool.
An elegant way to save issues as drafts until required fields are complete
We allowed admins to setup fields as required, but the experience was tailored to the field users, so that, if left unfilled, did not block the user from creating the issue. The issues were just created as "Drafts".
Before
All fields were optional, so any field except title and type could be left blank.
We allowed admins to setup fields as required, but the experience was tailored to the field users, so that, if left unfilled, did not block the user from creating the issue. The issues were just created as "Drafts".
Before
All fields were optional, so any field except title and type could be left blank.
After
All issue types containing required fields will be created as drafts until the required fields are filled out.
The ability to make fields required (Admin-only)
After
Easy process to make a field required on the web
Storyboards to narrow down the preferred enforcement approach
Initially, the team had thought that the hero concept of enforcing upon any status change was valid. However, there were differences in stakeholder opinions about the timing of enforcement. We needed to align on an enforcement approach that was also aligned with other stakeholder teams (platform team, Issues for Model Coordination and Design Collaboration). I put together storyboards as research prototypes to get feedback on the preferred approaches, both from internal teams and external customers.
Understanding the end-end flow based on technical constraints
Once we got feedback from research, we uncovered that both our approaches proposed were not fully satisfactory, and we needed to allow users to skip required fields at creation, but enforce them prior to achieving Open status for an issue. We then mapped the possible approaches of enforcing the required fields, system response and constraints. In collaboration with the PM, I designed conceptual system diagrams to determine the optimal strategy for enforcing required fields.
Conceptualizing possible approaches based on technical constraints
I then explored concepts to illustrate the two main approaches outlined above, for both the questions. I also aligned with the other teams involved (platform team) for sign-off on the approaches.
Approach 1:
Retaining the same status but enforcing required fields based on user choices. In this scenario, the initial status is 'open,' and the Back-End is saved as 'open.' However, the status change occurs only when a user attempts to bypass a required field. Automatic status change to Open.
Approach 2:
Assigning a distinct status (draft) to issues with required fields prior to creation, irrespective of user choices regarding field completion. Manually activating the issue status change to Open.
Storyboards to narrow down the preferred enforcement approach
Initially, we had thought that the hero concept of enforcing upon any status change was valid. However, we learned from our discovery research that could cause users to ignore issues altogether and perpetually be in draft state. We needed an enforcement approach before the issue was in Open status.
Understanding the end-end flow based on technical constraints
Once we got feedback from research, we uncovered that both our approaches proposed were not fully satisfactory, and we needed to allow users to skip required fields at creation, but enforce them prior to achieving Open status for an issue. We then mapped the possible approaches of enforcing the required fields, system response and constraints. In collaboration with the PM, I designed conceptual system diagrams to determine the optimal strategy for enforcing required fields.
Do what's possible within the technical constraints, but be informed
Upon further discussions, I gathered that we need to drop approach 2 altogether because of edge cases. I also gathered additional data to de-risk the solution approach: I extrapolated the legacy product data and found that the number of fields that were going to be made required is low, aka the proportion of issues will be impacted by this change is lower than we had imagined. Secondly, we were going to introduce this feature only on "issues types" and users had ~20 or so issue types on a given project. The impact foot print of risk should be managed by that as well. Finally, some of the edge cases were only on web and so we considered implementing this only on mobile.
Conceptualizing possible approaches based on technical constraints
I then explored concepts to illustrate the two main approaches outlined above, for both the questions. I also aligned with the other teams involved (platform team) for sign-off on the approaches.
Approach 1:
Enforcing required fields based on user choices. The status changes to 'draft' when a user attempts to bypass a required field.
Approach 2:
Assigning a distinct "draft" status to issues with required fields, treating them as a special case, irrespective of user choices regarding field completion.
Do what's possible within the technical constraints
Upon further discussions, I gathered that we need to drop approach 2 altogether because of edge cases. I also gathered additional data to de-risk the solution approach: I extrapolated the legacy product data and found that the number of fields that were going to be made required is low, aka the proportion of issues will be impacted by this change is lower than we had imagined. Secondly, we were going to introduce this feature only on "issues types" and users had ~20 or so issue types on a given project. The foot print of the that should be managed by that as well. Finally, we were considering if this can be allowed on mobile, as the majority of issues were created from using a mobile device.
