Marketplace is an internal app that controls all aspects of project development, such as API information, app health monitoring, code testing, analysis and developer / team contact information. Main users are developers and analysts. A project’s information would be stored in this site and accessed by developers and analysts that wished to connect their own services to any of the APIs listed here. The Marketplace reduces time spent on endless meetings discussing project details and connection arrangements. The Marketplace continues to grow today and is constantly adding new features to offer users more tools in GM’s ever changing IT world.
Initially, there was no place to save project information other than have it scattered to the 4 winds in endless SharePoint files across multiple domains with different owners that each required other users to request access to see those folders. Further frustration was the fact all information related to a project was owned by different parties, making projects have a lack of centralization. Information was abundant, but it was not to be found in one place. The constant chasing around of parties involved in the development of a project for questions or further information became frustrating, so a solution to include all that extra supporting information needed to be built as soon as possible. Over all, the organization needed to find a way to reduce meeting times and make the information more easily accessible and simple to understand. The problem faced by users of API data, encouraged the team to create a simple data repository center entirely from scratch, which grew in complexity over time.
Since all information regarding projects was spread all across the internal GM IT organization, getting information on a specific project was a hassle. In order to solve the many issues with the current situation, the most important requirement that came down the chain of users, was a desire to have a central place where all API information would be stored. The total requirements were a result of user observation, business needs and issues identified by the design team. In the initial stages of this project, design would bring in identified issues to discuss with other stakeholders and then expand on them via user interrogations. At the end of this step, there was an agreement to focus on the most important points in order to present an MVP version at the first stage. Later, additional functionalities would be added as the project grew, in part thanks to user feedback and user testings.
One advantage of this project was the fact that what was being created was a system for fellow developers and analysts to work on. This meant that for the most part, the users in question would be in close proximity and therefore present a unique opportunity for design to get to know them more and figure out what their needs and expectations about this project were. From the beginning, design was embedded with various development teams to see their day to day operations and collect user activities. The user information was a combination of surveys, meetings, observations and interviews that were done by leveraging tools such as emails, forms, excel, virtual meetings among other tools.
The main functions developed for this project were geared towards 3 main types of users. These were the developers, who were the main intended target and the one group who would use this product on a more regular basis. Another group were the analysts, who rely on project information to deliver their daily reports and help manage projects, and the last one, although on a lesser scale, was the group involving management, who, together with analysts, rely on critical API information to help steer the direction of a particular project.
Each group had its own combination of unique traits, skills and needs. Design leveraged these attributes to build a user centered design that would accommodate the unique attributes of each of these groups.
Through the findings of the user research stage and the classification of the persona types and their attributes, design was able to come up with a series of main user actions that would form the core of this project. In addition to the discoveries made in these previous phases of the design process, design was able to predict some actions via the day to day observation and immersion that was done within the development teams.
Design's arrival at these actions followed a standard brainstorming session, or rather, session(s), where user journeys were experimented on using the gathered data from the previous phases. After each sprint's brainstorming session was over, design was able to walk out with a clear course of action that would become a tangible asset in the subsequent phases of design.
Based on the various actions identified for each of the different types of users (personas), a structure that catered to the needs of all was carefully thought of. Such structure, at this stage was one that would instinctively help guide each user to its intended target. Researching established universal behaviors that are common between humans and computers, design was able to present a solution that involved a structure resembling a drill down approach. Such method would present the user with a cluster of elements that would be strongly related to each other. From those groupings, the user would instinctively know where to go to find its target or task. Such solution enabled the structure to present a universal structure without having to divide itself and present a unique design to each type of user.
The user journeys + actions enabled design to come up with wireframes that were distinctive of the type of structure that resulted from previous brainstorming sessions. Later, these wireframes would be put to the test when visuals and interactions were applied to them. Some, being changed in response to user feedback.
It was during this stage that developers are involved and asked for their input about the feasibility of the site's structure.
The final visual design was a culmination of around 3 different sets of designs over the course of around 3 years. Each new design attempted to solve a given issue at the time it was implemented. For this last final iteration, a combination of an already existing framework and an upcoming new GM design standard was used. For the existing framework, design and development decided to leverage the existing Materialize framework to build the skeleton of the MP's front-end. The decision for this was that it would be faster for development to use an already functioning framework as opposed to build one from scratch, therefore saving valuable time. The other combination was be the integration of a new design style which was in its starting phases. The use of it in tis project enabled a boost for this new design standard to gain some ground.
Visuals were kept to a minimalistic style, with emphasis on the main content, rather than on the pages themselves. The grey on white tone was consistent with the new General Motors' logos and the image the company was projecting in some of their consumer facing sites. After the framework was implemented, the new design standard was integrated with it and modified to live on top.
Prototypes were made in each sprint to test the various functionalities that were constantly being added. Some of the test targets were mainly the same users that design had used previously in the research phase. Depending on the complexity of the prototype or what was being tried to achieve, the prototypes were made using either XD or Axure. After successful completion of the prototype testing in which users were given a task to perform, design would then consult with development to establish any changes to the interactions if needed. When all green lights were given, the prototype, along with the visuals were sent over to development to initiate build.
Developers were involved in the design process from the very beginning of the project. It was important to have their input on the decisions that were to potentially affect the construction of this site. At the end, the developers already knew by heart what needed to be done because of the constant communication between them, design and project managers. The way design attributes were shared with development, was through tools such as InVision, documentation files, CSS and other indirect methods such as on-site guidance.