Project Goal - This project was the combination of a previous project (to build a communication and work history platform for industrial valves) and a second (to monitor new IoT "smart-valves") combined into one overarching system for the parent company and their customers. This new system would onboard IoT “smart-valve” clients, monitor and alert users to valve performance, keep work history records, messaging, scheduling, etc.

Stakeholders - Digital R&D director, CTO, CEO

Team Members -

• UX Lead

• UX Research (myself)

• PM (joined halfway through)

• Engineer

• Dev

• R&D Team Lead (Left halfway through)

• R&D Director

• Data Analyst

• Valve Engineer Manager

Timeline - No constraints, but the project lasted for roughly 2 years

Constraints - Almost everything already existed as an analog interaction or recording somewhere except for the information from and monitoring of smart valves. Moving an entire pen and paper industry into a digital space meant there were a lot of places to make sure the users weren't scared off by the transition. The management team had minimal experience with digital products so they deferred to our UX opinion quite often, sometimes to the frustration of other team members.

Steps -

• Reviewing of pen and paper process including internal email documentation of incident report and SOW document

• Mapping IA of system

• Creating UX definition sheets for the team to refer to

• Performing and analyzing 8 one-hour-long user interviews

• Quick Paced Ideation

• Adding system requirements based on research

• Creating onboarding process for new "smart-valve" system clients and sites

• Building the smart valve sensor hub installation that properly mimics the real-life hub (Configurator seen above)

• Fine-tuning sensor data analysis pages

• Designing dashboard widgets

• Designing customer-facing side of the software.

Results - User interviews and subsequent analysis helped us to understand what should be kept from the previous systems, which places we could help with low-level automation (specifically the creation of monthly customer reports), and places where the current analysis functions were lacking. The onboarding process was simple enough to create once the physical safety concerns were solved. The system for installing and verifying the sensor hub was complicated but proved efficient.

Challenges -

• Our stakeholders had very little digital experience so they regularly would not make any decision when presented with two or more equally valid options.

• The word "asset" was at one point being used to describe 4 different physical items and was highly contextual. This made internal communication about design and features confusing.

• A very opinionated and contrarian developer at design reviews.

• Massive and continual scope creep; as consultants, we didn't have the leverage to prevent this.

• The monitoring and tracking section for the smart valves was vast and had to be extremely detailed. The system needed to be able to scale from one user monitoring 10 pumps with multiple sensors to one user being able to monitor 250-500 pumps with multiple sensors.

Impact - My biggest impact on the project was the interviews I performed and then analyzed. I found that the initial scope of user abilities was lacking, but other than that the Engineering team had a good grasp of what they needed from the software. I also identified several places where the system would be able to automatically compile certain reports or streamline the analysis of sensors.

Challenges - The biggest challenge was simply the scope of the project. A global company that is very well established was now attempting to move a 10k+ workforce from pen and paper to digital process and we're building the system to handle all of that. Balancing the sheer size of the number of tasks needed to be worked on with how complex the varied tasks are, and not making a complete mess of a system to work within.

What worked well - For all its challenges and how complex the system ended up being, it was received quite well and we had immediate buy-in from users and stakeholders. This was thanks to the fact that from the beginning we broke the system down methodically and made sure every part we added fit well. This meant that by the end of the project, even when scope creep had really set in, the system wasn’t unwieldy. This structure helped reduce ambiguity later on in the project. 

What would I do differently -

• Not work for a fossil fuel client

• Defend more against continual scope creep

• Approach arguments with developers who want to override my professional recommendations with more gusto and finesse.