my roles: User Research, Interaction Design, Visual Design
Contextual Inquiry - Hitting the field to empathize and understand
Designing for construction workers in the field meant, well, user research in the field! I was able to meet and shadow various roles from companies like Clark Construction and Foulger Pratt. Some worked in the trailer and others also worked throughout the construction site.
While this company had been around for years, I was the first one to discover that many of our users had to wear safety gloves while using our iPad app. It turns out they buy special gloves that work with touch screens, just to be able to use our app.
More was learned each visit, such as how scanning items with bar codes for commissioning was very difficult for them when that item wasn't flat, like a fire extinguisher that is small and round.
While this company had been around for years, I was the first one to discover that many of our users had to wear safety gloves while using our iPad app. It turns out they buy special gloves that work with touch screens, just to be able to use our app.
More was learned each visit, such as how scanning items with bar codes for commissioning was very difficult for them when that item wasn't flat, like a fire extinguisher that is small and round.
Personas, Scenarios, and Journey Maps - Oh My
I built a set of Personas and Journey Maps that started to decorate our office. I didn't just create them and move on. They were "living documents" that I kept updated as we would learn more. These were based on real people, and as I posted them on our office wall, people gathered and started communicating. I was able to iterate on them, discover more of them, and get a deeper understanding about them with the resulting impromptu conversations in the hallway.
"You nailed Mark! He may or may not split his blueprint PDFs by area for Nelson, though." |
"Does every general contractor have a Nelson?" |
"Does Stan help with issues and punch list?" |
"Don is dead-on! He has to print issues each morning for his workers to fix." |
As I abstracted scenarios from my product managers, I asked them and colleagues from client services to join me for journey mapping exercises. At first this became a way for me to simply come up to speed, understand how our users got things done. I was able to get information from them they hadn't thought to tell me before - motives, missing steps, and missing personas. I literally had to draw new personas on the wall as we worked! These maps also became a vehicle for ongoing communication as we worked from release to release.
Blue stickies for the tasks of the journey, purple for the things they would interact with, and yellow (came later) for their emotions.
Blue stickies for the tasks of the journey, purple for the things they would interact with, and yellow (came later) for their emotions.
Updating the Experience
Until my redesign...
I took a role-based approach, separating project and administrative content into two clear places, and simplified the information architecture for the application.
First, I outlined a task-oriented architecture. I documented what the users should be able to do at the site, and then marked who should be able to do which things. This allowed me to create an information architecture for the application that makes conceptual sense first, then apply permissions to the content in context.
- the system permissions did not match the real world. They were pages and pages of permission settings that were not only unclear, but often conflicting. This left the setup to our client services team, an overhead cost to us, rather than empowering our users to manage their projects themselves.
- the experience lacked context, bringing application-wide and project specific settings, filters, and content together.
- the application overall was difficult to navigate and digest.
I took a role-based approach, separating project and administrative content into two clear places, and simplified the information architecture for the application.
First, I outlined a task-oriented architecture. I documented what the users should be able to do at the site, and then marked who should be able to do which things. This allowed me to create an information architecture for the application that makes conceptual sense first, then apply permissions to the content in context.