After documenting both blaster and driller tasks we asked users in each group to rate them by difficulty and visualized this on a matrix.
Tamara Oniani
UX designer
Project Overview
This product enables blasting engineers and drillers to design blast layouts, capture real time drilling and loading data and create reports on their tablets at a mining site. Nobel Fire has streamlined the blasting process and now all data can be accessed on the go.
Our team: Currently consists of 2 UX designers and 3 product owners. I work closely with the senior UX designer and the PO’s to research, define and design features that go in Nobel Fire mobile app.
Our goal: Optimize the Nobel Fire platform to be accessible in the field, so our users can easily capture data and create reports.
Timeline: 9 months
User persona – Drilling Engineer
Dyno mobile will be used by two primary users, blasters and drillers. Drillers receive blast designs and drill holes on site according to designs.
User persona – Blasting Engineer
Second type of users are blasting engineers who design blasts and execute them once holes are drilled.
First look At The Old Interface
High Level User Flow Analysis
The first thing I did to wrap my head around the project was to map out the current flow of the old tablet app in order to find gaps and obvious flaws that could be quickly fixed before diving deeply into analyzing the experience.
Then I reworked the flow to simplify it by getting rid of redundant paths and rethinking user actions that could be automated.
Instead of forcing the user to choose which part of the app to access upfront (drill log, Layout mode, hole log) we decided to have them choose these sections from a side navigation once they’re in the app. Additionally, we could make these sections show depending on user permissions to decrease cognitive load.
Dated Interface, unnecessary features...
The dated interface with bad UX was pushing users away and forcing them to find workarounds. Often users would print out a pdf template and manually fill it out so they wouldn't have to interact with the app. This workaround was causing inconsistencies and communication issues.
Pain points Discovered In Workshops
To begin understanding the issued with the current interface we conducted 2 workshops with our primary user groups – blasters and drillers. Below are the pain points we discovered:
Sometimes changes are made and it’s hard to tell what was designed and what was executed.
Notifications are pain points. Hand-off is imperfect.
Drillers shouldn't be able to change the original designs, this causes errors.
Consistency is the overarching goal/need.
If there needs to be a way to customize something, there needs to be a section where reasons for customization is documented.
Multiple users are allowed to be in the same drill log and it’s hard to tell who did what.
When holes are moved (drilled somewhere different than what was designed) there’s no way to tell.
Need a way to comment on individual holes.
File naming is inconsistent and some users even leave this field blank.
Fat fingering has been a pain point. (with zooming and selecting)
If something is degraded on a hole there needs to be an ability to highlight it as loose material and comment.
GPS coordinates on holes would be helpful to mark the nearest structure.
Currently there's no azimuth indicators on the diagram.
There's no need for drillers to be in any other mode than drill log, sometimes they accidentally end up in the wrong section of the app.
Summary (analytics) would be helpful to quickly see data.
Critical Pain Points
Sometimes changes are made and it’s hard to tell what was designed and what was executed.
Multiple users are allowed to be in the same drill log and it’s hard to tell who did what.
"Fat fingering" has been a pain point. (with zooming and selecting)
There's no need for drillers to be in any other mode than drill log, sometimes they accidentally end up in the wrong section of the app.
Sketching New Interface
Once we had a good idea of our user's needs, we started brainstorming some ideas. I made some quick sketches to communicate how I imagined the redesigned interface would function. I wanted to get rid of the confusing navigation that caused users to edit wrong sections by creating a dashboard where all blast designs would live. The dashboard would be the starting point for all reports for both groups of users and the rest would be permission based.
High Fidelity Wireframes
Hole Designations
We added hole designations at different depths of the hole to let drillers capture information as they go. Using a dropdown menu for designations standardizes the process and prevents errors. Additionally, users are now able to comment on each segment of the drilled hole if there are abnormalities detected.
Drilled vs. Designed Data
Sections where a driller needs to fill out information will be given two columns titled “drilled” and “designed”. we discovered that while drillers shouldn’t change the original hole parameters, they still need to see what was designed while entering actual data.
Moved Hole Documentation
When a driller moves a hole on a diagram to document that the hole was indeed drilled at a different spot than originally designed, the system will mark the original position of the hole with a faded dashed line.
Zoom in Interaction
Users can zoom in and out of the diagrams to comfortably tap individual holes as needed.
Defining Gestures
We redefined the gestures for the tabled app to make it intuitive. We documented these gestures so in the future we can create an onboarding experience to explain how to manipulate a diagram.
Testing As We Go
We also made sure to test elements as we designed by using Figma mirror and tapping around screens.
Navigation Confusion
In the old mobile app users were forced to choose which part of the app to enter and were not given any indication where they were once the decision was made.
We decided to incorporate a side navigation as a convenient way for our users to switch between app sections while also being aware where they are.
In addition, we decided to hide the navigation items that were not accessible to certain permission holders from them altogether. This will further prevent accidental editing and errors.
User login and permissions
We decided to replicate the Nobel Fire desktop app functionality and introduce the user account to the mobile app as well. User will be prompted to log it with an account created by the admin.
Each user will be able to complete and print out the report created by them with their name on it.
This will also allow the system to recognize users with different permission levels in order to display customized views.
Iterated For More Contrast
After Some feedback from the senior UX designer I updated this screen to have more contrast and match the rest of our screens as well as the desktop app better.
Design Objectives
Here is a list of principles we defined for ourselves in this project:
Prioritize accessibility with font sizes and contrast. These designs will be viewed outdoors, often in the sunlight, therefore the contrast ratio will need to be higher than standard.
Try elements of Neumorphism but keep accessibility as the guiding principle. Some of our users are not tech savvy and will appreciate the analogue look of design elements, however, Neumorphism is not always accessible so this is a challenge.
Loosely use material design guidelines.
Design for iPad mini (screen size 8.3 inches) for the MVP. Create mid fidelity wireframes for mobile phone screens as well to understand how the designs will scale down in the future, when we prioritize this device.
Don't use unconventional or complex gestures that our users may not be familiar with.
Test gestures to understand if our users know how they work.
Prototyping
Initially I prototyped a few screens in Figma but soon discovered that Figma doesn't have important features like zoom in, dragging and typing interactions. At this point I decided to research other softwares and found Protopie. Protopie ended up being just what I needed and with a small learning curve I was able to crate a well functioning prototype.
Testing
Testing prototypes before development is something that my team didn't do often. I strongly believe in putting the effort into testing upfront as it saves time spent on development by discovering the potential experience issues early. Since prototype testing wasn't a common practice I decided to propose a few softwares we could use as a side by side comparison in features and subscription prices. We needed a software that would allow both moderated and unmoderated user tests, would record screen and sound, and would work with ProtoPie (prototyping software I used to create prototypes). Lookback and UserZoom were my top choices and after a discussion with the product team we decided that UserZoom was a better option for our needs.
Tasks
Once we had the testing software selected and purchased it was time to create some tests! I wanted to keep the tasks high level and simple for the first round of testing. I created a spreadsheet of tasks asking users to create reports, blast diagrams and such.
After I reviewed the spreadsheet with my team I created a test on UserZoom and linked the prototype. We are planning to send out the tests to 20 users in the upcoming weeks and I'm excited to see the insight we get.
Next steps...
As of January 2022 we're ready to test the prototype. At the same time our developers are estimating the development effort of the MVP.
I've learned so much from this project and I'm really excited to see what the future of the product will look like.