On Automated Report Creation
To Improve Safety & Efficiency
Project Role:
Product Manager & UX Designer
Team Composition:
Leadership: VP of Technology, VP of Product
Design: 1 UX designer (me)
Eng: 1 software engineer
01 Introduction
First, a little bit about Blyncsy (pronounced — blink-see). Blyncsy built a unique traffic sensor that picks up your electronic signals as you pass through monitored roads throughout the day — without acquiring any of your personal or private data.
The data that we retrieve is completely anonymous and is housed in a secure database. This revolutionary service has made it possible to understand trends and give insights and analytics from the real world. Blyncsy Pulse offers a range of products that regularly gives users insights to traffic & transportation engineers. These insights are fully customizable and tailored to engineers’ projects.
02 Business Objective
The business objective of Scheduled Exports is to make the Blyncsy Pulse experience more sticky. We want to keep Eric (persona) and his team engaged with the Pulse data set, even if he has become passive in logging in and using the Pulse web app.
03 User Objective
Eric the Engineer cares about safety and efficiency on our roads. He’s looking for tools to help him do that job. Blyncsy provides valuable data to provide insights into what’s happening concerning mobility on Eric’s projects. Eric wants to automate his work to discover and evaluate analysis so he can spend less time doing repetitive tasks and more time taking action.
User Scenarios
Catalyst for use I
Eric the engineer is a traffic engineer for a road construction project. He has a weekly meeting, Monday at 10am, with his team regarding his workzones. Cones are out and work is being actively done on the road. Each week the team gets together and looks at the past weeks travel times for a few key routes.
Catalyst for use II
Annie the engineer is a traffic engineer who focuses on signal performance and daily operations in a urban/suburban environment. It’s summer and there’s a lot of events downtown and she wants to know how traffic is responding to the change.
04 Experience Audit and Problem
The existing system was creating too much confusion on use. Visually users assumed the scheduled export tool was broken. Labels weren’t specific in describing UI elements. Users wanted to be able to send reports with offset date ranges. This means creating a scheduled export is not a linear process. The tool must allow for nonlinear date ranges separate from the day of the week a report is created and scheduled.
- UI elements were inconsistent
- Error messaging used low contrasting colors
- Alignment of elements created legibility issues
- Inability to create a reports with offset date periods
- Use of copy was unclear
- Text color didn’t align with accessibility standards
05 Next Step — Formulate a needs analysis
The new Schedule Export push-out this time around had an acceptance criteria to be considered a viable product. As a team, we wanted to employ modern interaction design and so we built the modal in a push-out panel similar to Sketch and Lucid. Only this interacted like a drawer where it would collapse and extend with user input. At the time of development, we replicated an interaction Google used in its API Console instructional panel. Google had revamped that page around the time Material Design was updated. The acceptance criteria would need the following before we released it to our users.
- Sharing reports via email
- PDF & CSV report file types
- Creating offset date ranges
- Clear error messaging
- Ability to edit a scheduled report
- Preview report
- Email responses for specific customer roles
- Daily, weekly, and monthly reporting options
Me and team began sketching ideas on paper and in white-boarding sessions. Our office was also organized in a way that when there were questions about feasibility we could turn around and sketch out alternatives to a problem.
Once we combined the needs analysis and acceptance criteria we came up with a template of UI elements the push-out will contain.
The template was created for the developers to view as they began building the form and interactions between it and Route Analyzer.
Another part of the scheduled export project was defining how emails were going to work. In theory it seems easy, but there are different messages we wanted to display depending on responses. And non-responses. In the push-out form an engineer can invite others to receive regular reports. So, in our messaging we created several email outcomes depending on different actions. The following is a screenshot of how emails would be handled.
06 Usability testing
Before we made this live and visible for our customers I had some customers and team members who had not seen our progress run through some scenarios. The testing revealed that we would need to coach our users how to create a scheduled export. We did this through our training documents. The usability testing revealed that discovering the location to begin a scheduled export was hidden behind an interaction users didn’t often use. This was a huge oversight. We assumed users easily find the first step in report creation. Knowing this we continued with the release and created specific documentation in our Zendesk knowledge base.
07 What I’d do differently next time
At Blyncsy we operated at a very fast velocity. We also made changes during our needs analysis several times. Towards the end, our scope had become quite large. The developers and I would often say that we would like to ship an MVP version of scheduled export to see if our users would even use it. The fact is they used our oldest version regularly despite its obstacles. So, if I could do this all over again it would be getting our designs in front of our customers much sooner than when we did. I would also want to work more closely with our developers. I learned very quickly that the sooner I involve developers on a project the sooner clarification is reached.
