Digital Manufacturing Commons

A platform for the US manufacturing industry that encourages project collaboration and sharing of ideas, parts, and data.

Problem

Current solutions across the manufacturing product life cycle were typically made in silos and not shared across the industry. This led to costs going up and innovations to slow. The US military started to source their products from overseas because of this, which returned less than optimal results. More than 50% of the parts received, while less expensive, were not to spec and had to be thrown out. The US military envisioned a space where people and companies, both large and small, across the industry could work together to create better and cheaper products to help bring manufacturing back on shore.

Users & Audience

We sat down with GE Research, who was our client, to identify the audience and users:

• Project Team Member
  Works on project work assigned to them.
• Project Owner
  Ensures the project is running smoothly and brings in new assets.
• Store Front Manager
  Owns the company’s store front to market products.
• Call Respondent
  Responds to calls for help from Project Owners.

We acknowledged that an academic audience would exist in a future version of the site, and we would address this audience and their personas later. We verified the accuracy of all of our personas directly with users.

Our biggest takeaway from persona ideation was that our users had many differing goals. Some users would come to the site to find products and run models. Other users would act as an admin; accepting user requests, promoting products, responding to messages, etc. These users would require different onboarding focuses and visit different areas of the application.

Product Team

My role on this project was as a UX Designer and Project Manager. The team varied throughout the multi-year project, but it was primarily comprised of seven team members: a Visual Designer, a UX Designer, four Developers, and myself. The other UX Designer and I collaborated frequently sharing research and design ideas. As UX Designers, we were responsible for over nine sprints worth of wireframes, consisting of over 100 individual pages of wireframes passed to the developers. As Product Manager I was responsible for running scrum meetings, setting up sprints, making sure everything was on track from design and development, and coordinating between our front end team and the clients back end team.

Constraints

• Lack of Available Developers
  Although we had multiple developers on this project, these developers were working on other projects and assisting the client with backend services. Our sprints were adjusted to fit the developers’ availability, causing some sprints to simply be bug fixes. Having more Developers would have allowed us to develop the wireframes at the same speed that they were being designed, tested, and approved.
• Predefined Material Design Style Guide
  Our developers used Google’s Material Design to help create the site. When sketching and creating wireframes, we had to follow the material design style guide closely, as straying away from it would increase development time.

Design Process

Typically in our design process, we sit down with the client and discuss the problems that their users are currently having and create problem definitions. This project, however, the client approached us with the problems already defined for the bid they had won. We immediately delved into a discussion regarding the personas and their goals, biographies, touch-points, and more. We took the persona information from the client and created four primary personas.

A few months later, we were able to speak with users and verify the users’ problems. Users told us that they were lacking:

• A space to collaborate on manufacturing projects
• Access to models made by others cross-company
• A space to test run other engineer’s models in their projects prior to purchasing
• A place that allowed users to design, develop, and share manufacturing models
• A repository of Request for Proposals (RFPs)
• A centralized directory of small, medium, and large USA manufacturing entities
• A place to share subject matter expertise

Once personas were established, we worked through users flows to understand the site further.

We created an initial sitemap to help organize the content in such a large scope. Once we wrapped our heads around the content and features that needed to be created, we began ideation.

I worked with the Design Team to sketch and white board ideas, referencing design patterns for inspiration from sites including Amazon and Etsy. Once we were happy with the design, we created wireframes in Axure, tested them with users, and got them ready for development.

We worked with our development team to follow an agile process throughout this project. We created a handful of clickable wireframes, identified issues, set priorities, and assigned sprints. Any design or major bug fixes found during development would appear in the following sprint. We continued the cycle of sketching, wireframing, and creating sprints.

A few months into the project, we were invited to the primary customer’s headquarters for a manufacturing conference in Chicago, IL. This was the perfect opportunity to meet more users, verify personas, and perform user testing.

Doing this testing so early into the process, we decided to use clickable prototypes to perform the testing. We created task based user testing exercises. We asked users to complete various tasks, recorded their actions using Silverback, and wrote notes on their behavior and comments. We analyzed the results and presented them to the client. This user test taught us that our process flows were not as straightforward as we had expected. We re-examined our user flows and updated the site per our new user flows and user insights.

Almost a year later, we had a significant portion of the site completed and were invited to perform additional user testing at the client’s site. This was particularly exciting, because the client’s site had users that fit nearly all of our personas. We created a fully-automated, task-based user test. The users had the choice to select if they were going to complete one random task or all three in a comprehensive flow.

We had a significant showing of over fifty testers, leading to valuable insight. During testing we realized that users did not understand the purpose of the site. At this point we had never stood back and thought what it was like to be an unfamiliar user. As the day continued, we began explaining the purpose of the site, which alleviated the user confusion. Once testing was complete, we analyzed the results and presented them to the client. The client received many comments stating that users enjoyed participating in user testing and wanted to help more in the future.

Our largest takeaway from the testing was that the purpose of the site was unclear at first. This prompted us to create a clearer onboarding process, ensuring that real users did not mimic the frustrations of our testers.

Following user testing changes, the site was pushed live and funding was paused for a few months. With our remaining funds, we documented features and changes of the second version, and an interface inventory was created. The purpose was to identify inconsistent patterns to help improve design and interaction consistency. These changes would have been made with future funding, to ensure design and interaction consistency.

Results

The first release of this project went live mid-2016. We continued to work with the client to improve Version 1 and add additional content and features. Version 2 was supposed to include a way for users to link their services together, but shortly after we had completed Version 1, DMDII, the ultimate customer, decided to continue further development of the product internally. The success of the project is demonstrated by the number of users joining the site. More information about this product, Digital Manufacturing Commons (DMC), can be found by visiting DMDII’s site.

Retrospective

Focus Client on Problems Not Features or Content
We began the project by focusing on the client’s desired features and content, rather than the defined problems. As we sketched out ideas, we began questioning why certain features even existed in the first place and how they met user needs. After we met with the client we worked out what we wanted to test with users to find out if they were useful in solving their problems. From the start, if we had focused the client on the problems instead of features, we would have saved time and budget.

Using Agile instead of Waterfall
At the kickoff, we dove right into the project, prioritizing on the go and using the waterfall method. A year into the project, when I stepped into the project manager role officially, we realized that an agile system worked much better to focus us on planning priorities. This allowed us to finish features faster with better user testing results. If we had prioritized items within the scope before diving into the project, we would have avoided a lot of refactoring throughout the project.