What this is about
The Autodesk ReCap ecosystem is made up of 3 connected products that handle projects involving reality capture technologies. I identified a fundamental disconnect that went to the heart of the mental model of what a reality capture project is.
About reality capture technology:
This technology creates rich geospatial 3D and 2D models of the real world. Relevant examples include buildings and construction sites. Capture technology includes 3D tripod-mounted laser scanners, 2D UAV/photogrammetry, and newer portable in-field scanners.
About Autodesk ReCap:
ReCap consists of a desktop, web, and mobile app; respectively, they support 3D laser scanners, photogrammetry, and mobile 3D scanners. ReCap takes the raw capture data and converts them into workable 3D models that can be annotated, measured, and passed on into the wider Autodesk product ecosystem. These models would take days, if not weeks, for architects and engineers to model by hand. ReCap does it in hours.
Handy background note: ReCap was the result of multiple startup acquisitions. There are a lot of suite-wide inconsistencies that we sought to address, while trying to push new features out the door.
ReCap Web: as it was
ReCap Web was originally made of 2 major components: the dashboard and the project viewer.
The Autodesk ReCap suite in general is very visually oriented, and the major workflows are fairly simple.
- To view an existing project, you click the dashboard tile and go to the project viewer. You can annotate and export projects from here as well.
- To create a new project, you click the blue button in the dashboard to start that workflow.
Some issues with this:
There are other project controls and components that aren’t easy to find. This also disrupts the mental model of what a project is for users.
- Source files for a project (laser scans or source photographs):
- Location/GPS information for a project:
project viewer only
- Project exportables (to then be taken into AutoCAD, Navisworks, or other products):
- Sharing a project with other people:
- Project annotations, notes, and measurements:
project viewer only
A proposed solution: the Project Details Page
(This was built and launched without my awareness or input, or any user validation.)
The intent of the Project Details Page was to be a landing page for a project and all its metadata: once a user clicked on a dashboard tile, they’d come here first. Then they’d choose what data to interact with:
- the project viewer
- the project source files
- exportable files
- and so on.
Something about it just didn’t sit well with me from the beginning. It looked and felt very different. It felt like it disrupted the very visual workflow and interrupted the previous project-centered workflow with this new step.
On top of that,
- You couldn’t get back to the dashboard from the project details page.
- You couldn’t get back to the project details page from the project viewer.
- Therefore, in the project viewer, you had no access to any of the content in the project details page. And the dashboard commands and other projects were now off-limits since the dashboard was inaccessible.
This was especially bad because…
ReCap was evolving towards being an entry point into the Autodesk ecosystem, by creating projects via reality capture technology. These projects could be exported and taken into AutoCAD or other flagship Autodesk projects. We were being marketed that way and getting a lot of flashy press positioning us that way.
The project details page tried to expose a reality capture project’s metadata to make clear what a project was. But instead, the interplay between the project and its metadata was muddled. Everything was confusing and broken.
Trying to outline the real problem
I knew everything felt broken. Even my team knew this wasn’t a perfect solution. But nobody could actually identify why.
So, I took it upon myself to try to map out things at a fundamental, high level.
(These are the actual rough sketches I made in Sketch; these were for internal consumption and not intended to be high-fidelity.)
Yellow: how the major sections (dashboard, project details page, project viewer) linked to each other. Arrowheads indicated one- or two-way linkages. (As mentioned, the dashboard linked to the project details page, but not vice versa.)
Red: major functions and features, and what appeared in which section.
Ghosted/faded-out arrows: future/ideal connections.
To reiterate: ReCap was the product of multiple startup acquisitions. This lack of links was not deliberate. It was a years-long oversight.
Note that this includes mentions of 3D models and projects; that’s further functionality that isn’t necessary to explain to understand this problem space.
Beyond the components: what exactly is a project?
We were so caught up in showing users what a project included. But in working so hard to expose project data, it dawned on me that we as a team had lost sight of what a project even was.
After mapping out the above, I took a further step back. We couldn’t design an effective solution if we’d forgotten the problem.
ReCap existed to take reality capture files (scans or photos) and create an entity known as a project from them. Most of ReCap’s work was under-the-hood, creating a point cloud from those source files.
Included in the project entity was the generated visual 2D/3D model, as well as user-created annotations and snapshots.
From there, users could take actions on this project entity: exporting, sharing, or deleting.
As ReCap currently stood, this mental model was nowhere to be seen. The Project Details Page did indeed just add a frustrating twist to the workflow without reinforcing any of this.
This was a massive breakthrough for me. Getting back to basics revealed a massive flaw in our entire team’s approach.
A rough mockup to take to the team
Before sharing this revelation with anyone, I knew I needed a plausible solution to contrast with our current approach.
I did a quick-and-dirty “adjacent next” mockup on top of screenshots of our UI to show how to emphasize the project mental model in-context.
The biggest change here was including more robust linkage to other sections from each of the project tiles.
I changed the sidebar to a Project Details Pane, incorporating all of the metadata in the context of the visually-rich project. This still enabled you to access your source images, your exports, and your various views and annotations. I also offered suggestions to expose various tools that weren’t so findable before.
My team agreed immediately.
They completely agreed with my assessment about the Project Details Page and how disconnected we’d become from the overall mental model of a project. We escalated this to the overall development manager, who also agreed with my findings and that this needed to be addressed.
This had to be shelved for 6 months, but ultimately we did come back to it, and I took the lead on the redesign.
9 months later, the final redesign…
This is what we actually implemented, and I’m happy to say that it’s still in the product today.
Once you click a project tile on the Dashboard, you’re taken to a new Project Homepage, but this time it’s all part of a broader and more easily accessible Project entity.
The left-hand Pivot Panel is a component from Autodesk’s HIG. It’s a toggle between the Project Homepage and the different project views (2D and 3D).
The right-hand pane is persistent, and toggles between the source images and annotations. The content is dynamic depending on your view.
And the actual Project Details content area includes the same functions as before: opening the models, downloading, resubmitting the project, and sharing it.
But now everything connects. And everything is One Project.
The appearance is noticeably different because we started actively adopting parts of Autodesk’s HIG across ReCap. That influenced some of our design decisions, but ultimately it helped our work with unifying ReCap, as did having a very design-friendly team and a Product Owner who constantly dropped his own UI sketches off at my desk that he was happy to workshop at a whiteboard.
This is the most impact I’ve ever had on a product or project, and probably the most proud I’ve been of a project’s outcome.