Autonomous Vehicle App
Working on a team of three in my Inclusive Design and Accessible Technology course, I was to design an accessibility friendly autonomous vehicle ride hailing human-machine interface. There has been a focus on making vehicles more autonomous but it is crucial that disabilities be taken into account in the design of such technologies. My team and I worked with a visually impaired co-designer to design features that would allow the system to be accessible for individuals with visual and other types of disabilities. The first step of this process was to interview the co-designer regarding her experience with transportation, including ride hailing systems such as Uber, and her thoughts regarding self-driving cars. From the interview we developed a list of 20 user needs that our system should satisfy that were later grouped into six primary needs. Next, we conducted a brainstorming session of possible solutions to the primary needs. Ideas were structured into an affinity diagram which was restructured through iteration. The next step for my team was creating scenarios which were shared with the co-designer for feedback. Finally, with the help of the co-designer, task flows were created for the system. After the sessions with the co-designer, my team created wireframes for the system we named Autonomous Vehicle Accessibility System (AVAS). It consists of both an in car interface and a connected mobile application. All task flows and wireframes were made using Lucidchart. We created a prototype of AVAS by video-recording one of us interacting with some of the wireframes in a progression. To deliver our project we presented and wrote a report. This project taught me how helpful it is to set deadlines for each step of a project outside of the deadlines given as a requirement. As a result of setting voluntary deadlines, unlike previous projects for this class the time pressure wasn’t as stressful.
Task Flows
In Car System
Mobile Application
SmartGlove Interface
In my Design of Human-Computer Systems course, I worked on a semester long project in a team of four as a consultant for local company Modjoul. The goal was to design a prototype for the interface of a wearable technology, integrated into a glove, developed by Modjoul. The technology would display ergonomic safety data to the user (either an employee or employer). Having a well designed interface would allow employees and employers to easily monitor employee risk of injury. The project was broken up into four phases. The first phase involved interviewing stakeholders, the creation of a mission statement, the analysis of Modjoul’s current SmartGlove prototype and the SmartBelt (another wearable product) interface, and the identification of needs. The second phase involved establishing a hierarchy of needs through affinity mapping, narrowing the needs to address through the administration of an importance survey to stakeholders, establishing target product specifications, and competitive benchmarking. The third phase consisted of the creation of personas, concept generation, concept screening, and final concept selection. This phase was the beginning of the iterative process. In the final phase we created an initial prototype (using Adobe XD) on which we conducted a heuristic evaluation before conducting user testing. We iteratively redesigned the prototype based on findings from user testing and delivered a final prototype to Modjoul. For each phase we created a report and presentation; we included Modjoul in the audience for the final presentation. We competed with another team for best prototype and won based on Modjoul’s judgement. This was the heaviest project I had ever worked on in graduate school. My team met a lot for long periods of time. If I could do it over again, I would have set an agenda for each meeting so that we wouldn’t, for example, waste time on UI details and instead focus on the established goals. Anything else could’ve been worked out remotely or perhaps relegated as a task an individual was responsible for. Additionally, towards the end of the project, my team procrastinated due to a lack of communication regarding members needing more help in order to meet a deadline. This experience taught me that communication is important as is being realistic about how long a task will take. I could’ve agreed to help my team members when they said they were going to miss the deadline but even before that, during our meeting, I could’ve tried to predict how long the tasks would take each individual. Since I saw how finely detailed my team members made the wireframes, I could’ve reminded them that the professor cared more about following an established process than how pretty the UI was. Also, I could’ve reminded them of how little time we had to finish our project. Doing so would have led to less stress towards the end of the project.