PUBLISHING WORKFLOW

IVION is a reality capture platform for surveying, laser scanning, and AEC professionals.

What we set out to do, was not just to develop a feature, but to actually review, redesign and improve the workflow of IVION for our enterprise customers; but also allow the other customer segments to benefit from a faster and more streamlined process.

This was a complex project that took a year to complete, and my role as Senior UX/UI was to: help analyse the problem; design the new workflow, while still ensuring retention and engagement; conduct interviews; manage sprints progression with product management; define KPI and success criteria.

ROLE

Senior UX/UI designer

User Research, Customer research, Wireframing, UI design, Usability testing, Customer interviews, Data analytics.

Problem definition

Enterprise customers with large digital factories, in order to effectively conduct quality control of their digital factories, create duplicates of their instances or environments where they upload new point cloud scans, align them and proceed to check panoramic images (generated during the scanning process with NavVis hardware) and point cloud quality.

Once this is approved, data is downloaded again and then uploaded to the final instance/environment and made available to all end users of the digital factory.

This is to ensure that the final digital site, currently available to end users, doesn’t have issues and accurately reflects the real, physical site.

Considering all the steps described, this process takes several days to complete, since in most cases downloading and reuploading larger bundles can take hours.
At the end of 2022 an initiative was started with the goal of redesign the entire IVION workflow, to streamline and make the whole process faster.

Our north star: speed up this process and allow users to work simultaneously on live and new data.

Problem statement - collection of notes using the 5W + 1H method to define the problem

Using the 5W + 1H method, we collected ideas and answers around the questions who, where, when, what, why and how, in order to better define the problem

Initial research and user roles

After collecting the initial insights from the feature requests, we kicked off the research phase with a series of enquiries to the internal customer facing teams.

The goal of these conversations, was to get a better understanding of the current user flow, how do they currently solve or circumvent the issue, and who are the key user roles involved in the process.

We also identified the following roles:

  • Scanner – does the scan and uploads the data.

  • Data Processor – responsible for site setup (admin).

  • QA group – customer side, they do the last quality check for the approval.

Key considerations for the first iterations emerged as the conversations went on, that helped us limit the scope and focus on top priorities, such as, limiting the different workspaces to 2, one draft and a published one, to avoid introducing more complexity with branching.

Simplified customer flow, used in presentations to highlight the problems in the process and where the pontantial solution could be. Use case: adding new point cloud scans to a site

Workflow and initial concepts

Me and my colleague got to work on creating a diagram of the workflow, in order to highlight the main pain points, and find the best areas where improvements could be introduced.

As the next steps we refined the flow diagram, including the option to “publish” the changes to end users.
We then conducted a brainstorming workshop to gather thoughts and ideas from the development team; the objective was to assess the mental model from tech side, and used the results to help us define the workflow better and define what was going to be out of scope.

We clustered the result and reached the conclusion that the best approach was to go for a CMS – content management system mental model.

There were still questions that needed answering and technical investigations to conduct, so time for some spikes and testing.

Customer workflow, more detailed, with the inclusion of the user roles previoulsy described (see user illustrations).
Data acceptance and published site are used to identify the two separate environments, the red sections highlight the issues.

First simplified wireframe, used as a visual guide of how IVION might be affected in the frontend.
We started brainstoming layout ideas as the develompent team was working on spikes to answer technical questions.

Usability testing & the final concept

I decided to conduct A/B testing to evaluate different UI options and flow, and facilitated the sessions together with the PMs on the project.
I then used the transcripts and tools such as condens, to consolidate the findings and present them to C-level management.

Now we had a defined flow and UI, stakeholders were aligned on the next steps and spikes were being conducted by the dev team.
I wrapped up the concept, bringing in all the results of the different research streams, and made sure to detail all the different flows relevant to the workflows and user personas.
This was a time consuming process but much appreciated by the developers, as they could easily get from confluence to a live figma document detailing all the different branching paths a user could take based on role and permissions in IVION.

With tickets being constatly refined and pulled in sprints, and tracking events being implemented for the analytics, I focused on supporting QA with testing scenarios, documenting bugs and issues for the first Alpha release.

Usability testing prototype, used with customers and internal stakeholders to evaluate, with the guidance through two simple tasks, what layout proposal scored better in terms of usability and intuitiveness.

New updated customer workflow proposal, with the inclusion of the user roles previoulsy described (see user illustrations).
This is time around all the changes can be done in the same environment, and publishing, instead of downloading lots of data, for this to be loaded again in a different virtual location, only requires the press of a button saving days of work.

Prioritisation for the MVP 

Following the suggestions of our program management team we opted for an alpha version with a small release scale, and use the results of the feedback as the base for the first larger main one.

As the date was already set, we had to prioritise what additional changes were going to be included in and what pushed back to a second iteration; to choose what was the most important and keep everyone aligned we used the definition of MVP.

Everything that was either not used to solve the main pain point, a UI preference not backed up by data and findings from anayltics or interviews, or too resource heavy and would miss the deadline, was deemed out of scope for version 1.0
The excluded features were kept in the backlog of the team, ready to be picked up in case of customer feedback, post release.

Working on the flow highlighted the need for better separation between admin and end user flow, for this reason the different tools in IVION are now separated between draft and published site. The diagram above served the purpose of illustrating this separation to C-level management.

Above is the final, high fidelity handoff file, given to the dev team, showcasing the different option when navigating the new UI for the publishing workflow.

Release process

UI was blocked, internal feedback was being collected, bugs were being fixed and customer education team was hard at work on the education material and documentation changes.

I was working on the mixpanel dashboard creations to start collecting all the data analytics based on success criteria.
We succesfully hit the anticipated deadline and no issue on release were encountered.

Publishing workflow was out to the majority of our customers, and we can say that we met the success criteria initially set of helping our customers:

  • Before a lenghty process that took several days to complete, now only takes few hours.
  • Before downloading data and then uploading it again between sites took hours, now with the simple click of a button takes only few minutes.
Retrospective

The constant iterative loops of the project, were a determining factor for its success.

Getting the feedback of management and stakholders early on, avoiding to jump into solution mode immediatly helped streamline the process and save time on ideas to complex to implement or just not focusing on the right problems to solve.

There were still some bugs that were discovered after release, as well as issues that we failed to test, and we are already working on that.
We’ve learned from the missing test and we’ll improve with the next iteration, but considering the major workflow change, and the small amount of issues discovered, is still a great achievement for the development team.

It was a great experience learning how to facilitate the development such a big product feature, from problem definition to release.

More projects