DFOAB (Dealer Fixed Operations Advisory Board), or "Dealer" for short, is a tool that provides a space for dealer personnel and GM staff to interact with one another when issues arise in the day to day operations of a dealership. The dealer will post an issue to this space, which then, an administrator will take the issue and assign it to an expert in the subject the dealer is having issues on. A “Scribe” will post a solution back to the board for all other dealers to see and give their feedback on.
The old DFOAB site was a bonus add-on from a system that was created some years ago. The user interface did not create a clear path for the different types of interactions and tasks each user needed to do. As a result, the tool fell into disuse and became obsolete over time. Some of the bigger grievances the user research revealed was a frustration with the usability and design of the tool. The old tool looked more like an excel spreadsheet with tables everywhere and cumbersome navigation menus. Roles were not defined so the landing page did not provide a direction on how to begin a task. Also since the tool fell into disuse and neglect, users tended to abuse it by posting rather controversial issues to the tool, which caused disengagement from the GM team, (the very team that was supposed to help these dealer personnel solve their issues). Overall no one was held accountable and issues posted to the board went unanswered for long periods of time, some even never got a response.
As a second-grade app that was installed as a bonus add-on, this app tended to be passed and ignored all the time. When management decided to revamp the app, it was established that in order for life to come back to this app, some crucial goals needed to be met. Some of these goals were to increase and improve user experience, make the app more available to the intended demographic, help user collaborate between each other, and as a bonus, set the app as an example of what a design approach could do to the benefit of other future projects.
The team involved consisted of a sizable group of designers specializing in UI, UX and research. For this portion of the design phase, the team appointed the research team to lead the effort to collect user information. To accomplish this phase, the research team divided up the task into two targets: users and stakeholders. Following this approach, the team spent time on-site with users observing their interactions and learning their day to day operations. In addition to the observation, the research team also prepared a series of questionnaires for the users to answer during scheduled meetings. The other portion, the stakeholders (business, committees, admins), were interviewed in a series of video-conferencing sessions to gather insights of what were their needs, expectations and other wants for this project.
At the end of this phase, a large meeting took place with both targets where a comparison of needs was presented with the design team helping bridge the gap between users and stakeholders in order to get a better understanding of what the requirements for this project were going to consist of.
After the research phase, the team found out what types of users the new version of the app needed to focus on. At the original stage, the app was free-entry-for-all-site that offered no specific guidance to any user. What followed, was a need to differentiate the main types of users and to start building the new version in a way that it would cater to their different needs. This was done with the hope that in the near future, the new design would help attract more users and increase the value being offered to the organization.
Persona and user research phases gave design a clear picture of what some of the user actions were going to be. From here, design took on a game of "what if", and asked the main hypothetical question of what the user needed to accomplish a certain task. A "as a user I need to..." was passed around the team as we worked to come up with every single user action that might arise based on the type of user, their needs and other situations gathered from previous research. From here we were able to put together some core functions that were common across the 3 main types of users.
Much debate went into the structure of the site, with many hours spent on trying to figure out the best way to accommodate all the new functions that would be accessed by our 3 main users. A decision was made to split the app into 3 different starting points, each designed to cater to the specific needs and wants of each user. A dashboard approach was agreed on. This dashboard would contain the most important tasks that user had on a daily basis and display such tasks at the forefront of the app. From there, the user would decide where to go based on what his/her day looked like.
The visual design portion was a take on the emerging GM internal design standard. At the end of this project, this design helped spread the awareness that a design system needed to be adopted and standardized. By going with this style, the team made sure that the face would speak to the style of what GM was trying to become. Colors, formats and styling was chosen to represent the new GM grey on white logo and the future of the company.
Addition of some social media features made the site produce a more familiar tone among users. This was done to help users associate tasks and procedures with other behaviors they were already familiar with in the outside world.
As with every project, meetings were held with all stakeholders involved in getting this project off the ground and into development. The prototypes helped the design team establish a series of rules going forward in the development of this project. Developers, and stakeholders would use these prototypes to give in their input as to the direction of the project. Users would access the prototypes from time to time to test some features and therefore, allow the design team to make any changes if any, based on the feedback it gathered from both users and other stakeholders. Finally, the designs were a combination of files made with InVision, XD and finally Axure RP.
Having worked side by side with the development team in the creation of this app since the beginning of the project, the developers were able to contribute to some of the decisions that were made by the design team. Most of these decisions had to do with the classifications of priorities, meaning that development acted as a guidance on where to focus more our resources based on the realities the project faced in terms of technology and feasibility. The development team was able to reuse an existing framework and decrease time needed to fully code the site. In addition, some functionalities of the app were scaled back due to technicalities and it was decided to release them at a later time in new versions. Thus, a series of initial versions or MVPs began to be rolled out at the end of the design phase.