Environment Canada

In between my third and final year of my Industrial (Systems) Engineering undergraduate degree at the University of Toronto, I worked as a Business Analyst for Environment and Climate Change Canada under its Severe Weather Forecasting department. During my 16-month long internship, I was exposed to a variety of roles and responsibilities that served to broaden my skill set so early in my career. I learned a great deal about meteorology and forecasting while also gaining an appreciation for how government systems broadly function, specifically how they deliver software. 

While my role was that of a BA, I sought out design opportunities wherever I could. Most notably, I served as the interface designer for a metadata management application used by subject matter experts across the country to store vector coordinates, XML, and geographical and meteorological data. I joined the project about 2 years into planning and execution. By then, an MVP had been developed and I was slated to work on designs for V2. While the application consisted of standard table views with sorting, filtering, and search features, the challenge came when designing for the data governance and change request requirements. Managing the review of data, specifically conveying to the user how it passes through its various business states before it is instantiated in the database is a complex endeavour requiring designs for use cases related to updating, retiring, creating, and denying the implementation of new data. Each use case contained business rules subtitling different from the others, culminating in a set of 100 Balsamiq mockups, not to mention the plethora of designs that flow from error handling, all constrained by the Government’s strict accessibility requirements. In situations like these, I learned the importance of site mapping and how to meticulously document user flows. This allowed for an organized approach to the design of each webpage ensuring nothing was missed. 

I was able to flex my budding user research knowledge on a project aimed at revolutionizing how severe weather alerts are issued by forecasters. The AS-IS model for issuing alerts sees forecasters click on vectors associated with municipal regions projected to be in the path of severe weather (thunderstorms, tornadoes, hurricanes, etc). This workflow is integrated into the user’s weather forecasting software allowing them to overlay radar and satellite imagery over these regional maps to determine which areas should be alerted. The TO-BE model would see forecasters use tracing tools to outline weather events and alerts would be issued automatically. This method was hypothesized to better integrate with the user’s existing workflow as they are also tasked with issuing daily temperature and precipitation forecasts that utilize similar radar and satellite data. 

Together with two Senior Business Analysts and two Junior Meteorology SMEs, we set about validating the inherent assumptions of the TO-BE model by shadowing forecasters working on the desk. We were able to observe the forecaster’s workflow noting primarily, 1) the information they used to assess the general climate and in what order it was accessed, 2) how they monitored severe weather and how they issued updates to previous alerts, and 3) their thought process when it was time to issue a severe weather alert. Together with the team’s own analysis of the AS-IS software, we collaborated on a report detailing our findings and recommendations. A crucial point arose when discussing how to model events that develop over time with 2D vectors. Having vectors move in a snapshot fashion over time, automatically selecting and deselecting underlying regions to alert, requires a fair amount of sketching on the part of the forecaster. Each snap shot contains a forecasters sketch of weather events at that point in time and space. These sketches often looked like blobs moving across the user’s screen shrinking or expanding over time. We knew that allowing the user to quickly make these blobs, with minimal clicks and drags, must be top a priority. Although designers use similar tools in our software to create vectors for components, forecasters do not require the same granularity and thus require tools suited to their specific environment.

Tools

  • Balsamiq Mockups

  • Ninjo Metrology Software

  • Lucidchart

Skills

  • Requirements gathering and elicitation

  • ER diagramming

  • Business Process diagramming

  • Quality assurance testing

  • Low-fidelity design

  • Task Analysis

  • Ethnography

  • Usability Testing

Previous
Previous

EVNTL