Hello! I’m a Designer about to graduate from Systems Design Engineering at UWaterloo. Most recently, I interned at PlayStation Network. Now I’m looking for a full time position where I can continue to develop my career and passion for design.
In my 3A term, there was a 3 month-long group design project, starting from finding a problem to developing a functioning prototype. The constraint was that the project had to utilize the Internet of Things. Our group was also given the category of Industrial Controls to work with. We created a wearable system that detects hazardous gases on oil and gas work sites and relays the information to both workers and managers via a mobile application. A demo of the prototype is here.
We decided to focus on the oil and gas industry for our project, since it is extremely relevant to the Canadian economy, as well as the topic of Industrial Controls. I interviewed a variety of people in the industry, including field workers, field supervisors, and higher up managers regarding safety issues on site. From these interviews, we found that H2S, a toxic gas, is still a major safety concern, since it can be fatal if exposed to it. This led to the development of the following problem statement.
In current oil and gas industries, numerous employee illnesses and injuries arise as a cause of unsafe working conditions. Through the use of sensor detection, various unsafe conditions regarding toxic gases, temperatures, and air quality can be addressed before harming workers. Although there are current solutions, such as employee training and alarm systems, these methods prove to be ineffective as the number of injuries and illness have not been eliminated. Thus, this issue still remains and must be addressed.
Currently, it is mandatory to go through H2S safety training before entering an oil/gas work site. It is also common for workers to wear personal safety monitors, which detect various gases and alert the wearer through beeping and/or vibration. However, the problem with these, is that they don't alert other employees and managers of the issue. The worker must then report the issue, which often does not happen. Poor communication and lack of reporting up, often leads to gas leaks not being fixed in time. Also, other employees are not aware of the detection, so may come across it themselves afterwards. There is no reliable documentation of issues. Also, the devices do not communicate with one another, which can prevent necessary assistance from occuring during emergencies.
A variety of concepts were brainstormed and analyzed. These included biometric measuring, a drone monitor, an automated lockdown procedure, and gas neutralization. The final concept decided upon was a wearable device which monitors hazardous gases (i.e. hydrogen sulfide, carbon monoxide, methane), communicates with a central system, and provides workers with alerts for any hazards in the workplace.
My primary role at this point was to design the mobile application. A mobile app was decided upon, since all field workers always have a phone on them.
To decide on the app's architecture, I created the following table, after brainstorming features.
Based off of this, I created user flows, one of which is shown below.
After many sketches and iterations, the final version for this class was created. Orange was chosen as a primary color because of its strong association with safety. Blue was also chosen for its calming effect. Cards were used to distinguish between different hazards, containing critical info. Each one is colour coded to display the severity rating. Various levels are determined and set by existing safety regulations.
The dashboard is the app's main page. It displays the user's safety status, based on gases that have been detected near them and their severity. Below, it shows the gases recently detected that are affecting this status.
Each hazard can be tapped on to see details, such as the recommended safety procedure, predictions, and the location it was detected. Users can also add notes regarding the hazard.
The user can see all the gases detected on their site. These are viewable in list, map, or graph form.
The icon in the top right corner opens a side navigation, which displays all the workers on site, as well as provides the ability to contact them.
Supervisors also have the ability to view all the work sites and their current safety status.
Users can also view the history of gases that their personal monitor has detected.
Lastly, the side navigation is shown below.
The prototype consists of a wearable device connected to a mobile application via the Internet of Things. For testing purposes, alcohol gas was used, since using toxic gases would be dangerous at the demo. There was a radio frequency component which allows the prototype to have wireless communication between different devices and the base station. This is used to transfer the data from the sensing node to the base station. A screen is used to display the concentration of H2S and Alcohol Gas in PPM on the device. An Arduino Nano is used to gather the sensor data, interface with all communication and visual components. The Arduino Nano also has basic logic which allowed onboard actuation. Alcohol gas and H2S gas sensors were included. A vibration motor and LED were also included to be used in conjunction to notify the wearer that a dangerous gas was detected.
The data collected by the wearable is then viewable on a user-friendly mobile application. On this application, the user can view their safety status, as SAFE, CAUTION, or DANGER, depending on the gas levels near them. The user can also see the history of all hazards at their worksite in list, map, and graphical form. Since there are often many worksites which workers travel between, they can view a list of the safety statuses of all sites, and easily switch between them. For each site, there is also a list of all of the workers on site, with the ability to call or text each worker. This ensures that no person is forgotten in the case of an emergency.
In case you missed it the first time, a demo of the prototype can be viewed here.
This project had achieved a number of goals that were set at the initial phases of the design process. Two of the greatest successes in the project are outstanding functionality of essential components in the prototype and flawless execution of the prototype demonstration at the design symposium. The prototype was able to demonstrate, with a near 100% success rate, the capability to detect ambient concentration of alcohol, perform analytics on data received, and use IoT features to display information in an easily accessible format.
Some of the failures that were noted are incomplete functionality for the secondary objectives of the web application and the lack of a few desired features from the prototype. The entire functionality of the web application could not be completed due to time constraints, therefore a few links were inactive. This issue can be corrected by proceeding with the second phase of the design process which would be to address the secondary objectives of the product design. The desired features that were missing from the prototype were GPS tracking and LCD display for alcohol concentration. These could not be implemented due to hardware constraints of the Arduino Uno board. The number of input pins and power output required had exceeded the capabilities of the Arduino. Also, there was no time to conduct extensive user testing on the application. In future iterations, the app's design needs to be tested by actual potential users.
One of my projects at PlayStation Network was to adapt the PlayStation Video app for iOS. At the time, it was only available for Android. iOS design standards are different than Android's, especially due to the constraint of not having a built-in back button. Also, a business decision was made that videos would not be available for purchase in the iOS app, as they are in Android. This created a design dilemma on whether to include browsing in the app or restrict the app's functionality to strictly playback for videos purchased on other PlayStation platforms. My process involved research into differences between iOS and Android standards, journey maps to compare the two browsing options, several high-fidelity prototypes, and testing in InVision. My slide deck for my work is shown below. In the end, Variation 6 was chosen. Even though it is less of a native iOS design, it was most feasible to convert software-wise.
One of my tasks at PlayStation Network was to create personas for the PlayStation web store. I researched why people use the webstore, rather than the console version through interviewing users and reading online forums. I found that the 3 primary reasons were so people could buy items at work and remote download purchases to the console, so they wouldn't miss deals while on vacation, and because the PlayStation controllers are inconvenient for navigation. From this information, I developed the following personas. The color scheme of the personas is that of the PlayStation website.
For the winter hackathon at PlayStation Network, my team chose to develop a better recommendation system for the PlayStation Store. Even though this project was primarily back-end based, it was determined that a well-designed UI had to be created for the demo in order to effectively present our project and its results to the judges. We ended up receiving an Honourable Mention award.
The current PlayStation recommendation does not give helpful recommendations. It generally recommends the most popular games at the time, regardless of the user's preferences or the product being looked at. For instance, there were many children's games where violent games such as Call of Duty would appear as recommendations. The goal is to improve algorithm accuracy, and thereby increase sales via recommendations.
The main purpose of the demo was to demonstrate that the recommendations provided align with the games chosen. Since the UI was separate from the Store, a selection system was decided upon to replicate user's purchases. Therefore, the user had to be able to select multiple games. A search feature was also needed, in order to demonstrate that the recommendations can apply to any game, and not just the ones immediately populated. The user also needed to be aware of their choices while viewing their recommendations in order to emphasize recognition over recall. Some other key requirements were the ability to deselect, see what's been selected, and to clear all.
Several wireframes were developed, some of which are shown below.
User selects the games they'd like to see recommendations for.
The tooltip allows the user to see the games they've selected.
Page of provided recommendations.
By the end of the hackathon, the recommendations were considerably improved. This fact came across to the judges, and we received an Honourable Mention for the project.
The site can be viewed live here.
This was a small feature I did while working at PlayStation Network. The ability to watch a trailer had to be designed into the application, as well as the mobile web store.
A variety of low and high fidelity prototypes were created (unfortunately I no longer have most of them) which presented various options including buttons, tapping on the image, a trailer section, etc. One of the final iterations was the following.
Unfortunately, for various reasons, it was decided by management that a still from the movie could not be included. So, this version was iterated on to instead include a graphic, which I created in Photoshop. This led to the final versions for mobile and tablet below which are currently in production.
During my co-op term at OMERS, I was in charge of creating a yearbook of sorts for the co-op students, with the assistance of Erin Leach. I created it almost completely in Adobe Illustrator, with some photo editing done in Photoshop. In case you haven't guessed, the main part of the sun on the cover is the O from the OMERS logo.