Making Sourcing Digital, UX/UI Case Study.

The Omnae Web App

Freelancing Contract, March 2017

The Opportunity & Challenge:

Padtech has been a leader in global sourcing for 25 years, allowing global companies to do global manufacturing and sourcing through its thorough quality assured processes. Global sourcing is the creation of a physical product from design into prototype then production via an array of worldwide manufacturers or producers.

Padtech has been successfully using their method for decades, however, with the digital age advancing upon this industry, there was an opportunity to create a web application for this process. Recently they have started development on an online version of their common practices named Omnae to streamline and digitize the process. Padtech came to me to adapt this Omnae prototype application by applying UX and UI practices to optimize a tried and tested process of business.

Within two and half weeks I was to create a digital platform that worked for the users and web developers of Padtech without altering a solid business model or making a platform unfamiliar to the common industry practices.


Research:

The majority of the research phase was devoted to the understanding the global sourcing domain and heuristic analysis of the previous prototype. Global sourcing only briefly ever crossed my mind, so to be apart of the industry for two and half weeks was an interesting and enlightening look into how the things I’ve come a custom to using were made. Almost everything around us today was created or produced in a different country then shipped over here, and I was learning how that whole process happens.

This business process has been used for decades and is accustomed to the industry, so it was paramount to my client and the users that whatever I created was following this procedure, not destroying it. It is considered a trade secret so I cannot disclose the exact parameters in this case study.


Key Insights

With that process in mind, I set off to reach out to the regular customers that would eventually use the Omnae platform. The key insights found from the interviews and research I conducted were as follows;

With quality and knowledge of parts status a prevalent trait of interviewees, It was back to the initial prototype to see if it could easily display those two.

This is where I found the first areas to expand and take this design to the next level. The prototype had a major lack of layout and consistency, harming the experience users would encounter.

Understanding the list of states a part would encounter lead to the designs most valuable feature, the part card. Thinking in a production mindset, the user’s product has to follow a production line digitally and in reality. It can go back and forth and be held up while being built down the line. The trick is making sure the user knows 5W’s at all times during this process. The way that was achieved was with the part card which I will touch on later.


Planning:

Now that I know what I had to work with, I needed a way to let the user know where their product was along this “production line”. By using the common knowledge of a production line used in modern mass production, I can use the imagery of a box along with a conveyor belt arriving at different stations along the line.

This is how I met the project goal of not altering the current business model and adapting the digital form to reflect it. The design translates what is happening in the parts actual production.

This production line has many milestones and some of which being points where the part could go back a step depending if the development was going smoothly or not. The previous prototype had a way of displaying the current state of a part, meaning what milestone it was at could be considered its state. but was unclear to what that meant in relation to what was actually happening to the part.

For instance, if a part is in a state of “approved sampling” then it recently just reached the milestone of an approved sample, but the only way the user knew what that meant was through an intrinsic knowledge of the industry.


Navigation

As for the top down view of the web application, the site mapping was adapted to reflect the new screen layout. Thus meaning, new pages following the same layout structure were introduced. This was done to help categorize the data and parts in and out of production. Previously, all the parts in all the different forms they may have would be on the dashboard. That idea stayed but was altered to help users navigate the app.

Along the top nav bar, new pages were created to further de-clutter the interface and data stream to the user. As you will see in the examples, there are new pages available to the user. The reasoning behind this is to separate parts in categories. The parts in “Alerts” are the ones that have recently made a change in state or have been updated in production.

Old Wireframe, Notice the lack of navigation.

Parts in “Orders” are being worked on and don’t need any interactions, rather more of a tracking sense of attention. Parts in “Products” show all products the user has access to, allowing users to go back and reorder or edit parts.


Design & Testing:

The reason the old prototype had an information overload is because that this type of business is detail intensive. At each step of the process, there can be a multiple different messages or points of interest that may or may not have to addressed right away. The simplest way to develop a platform like that was to display all the data no matter what, that doesn’t mean this was the best way to design it.

Where the previous prototype showed what state the part was in with just simple text, I found a more effective way to show state through my iterations, state icons and “hover overs”. Previously, the user would have to intrinsically know the meaning behind the state naming and was lucky if they could glean information from that. The choice was made to show an Icon that was colour coded to what part of production it was in and what action it was in. Additionally, the user could hover over the card to get more detailed information through progressive disclosure rather than a barrage of data, and then, in turn, interact with that hover over.


Layout

The idea of the cards was carried over to the new design but tweaked and simplified, however, the basic page layout had to change as well. Previously the dashboard had three columns were parts in different categories would be placed and interacted with.

Old Dashboard.

There was a lacking consistency of what was displayed, even though that what had to be displayed for the parts production would be changed periodically. The reasoning was sound and created in a purely functional form with a limited timespan. The ideas and processes were all thought out, but the execution wasn’t there.

The new layout developed needed to change the screen layout and space for interaction.

New Dashboard in the grid format.

In this new layout, you can see the part card system as well a less crowded display language. Other than the addition to a new way to show parts and what state they are in, there is now a navigation bar. Adding in new pages and access to settings. Further joining to the idea of progressive disclosure and showing the user on what they want, not all of it immediately.


State Icons

The icons serve to help the user with a quick association to the cards current state. The colour coding is to designate what sub production the part may be in, for instance; Proofing icons will all be in the same orange coral colour to help users associate what state and phase that particular part is in.

Again, to not disclose the trade secrets, I cannot show all of the icons created for this project for it would reveal the production process. Here is just a small sample with altered names to not disclose the process.

In a set of A/B test cycles. The cards with associated icons yielded better results and better goal acquisitions among testers than the cards without. Thus they were here to stay.


Card Functionality

The card also now has to perform a few actions depending on where along it is in the “production line”. When a part is held up by a purchase or revision challenge, the image will fade when hovered over to show a call to action that sends the user to an interaction page. When in the production phases, the image will fade to show a milestone list.

“Screwdriver Body” on the top left is being interacted with in this image.

In this case, we are looking at the “Screwdriver Body” part, the large open area of the card fades into an action state that prompts the user to view the request to purchase. This in conjunction with the yellow alert state icon prompts the user to act upon this part and helps continue the production process.

“Rubber Mallet Head” on the top centre is being interacted with in this image.

When a “Revision Challenge” is needed on the part, the image area fades to show a similar action to the “Purchase Needed” action. Rather sending the user to the payments page, it sends them a page showing why the part needs to be revised, a common instance in this process to assure quality.

“Framing Hammer Handle” on the top right is being interacted with in this image. The milestone list had to be blurred to keep secrecy.

When in production, the image will fade to show a simple milestone list. There are current no actions the user needs to do to help this part along with other than keep track of what milestones it is in. If the user wishes, they can go to the parts page and reach out to the factory correspondent for an update via an email link.


List Format

List versions are for users that may have more than a few parts in production, to help a large business with hundreds of orders or parts in production.

This is a mock situation, not an actual example of the process. Form applies to other types of interaction.

They still allow the same level of interactivity, however in an elongated and more compact form. To activate the action, the user will click on the listed card, then the area of interaction will come in from below.


Testing

During the first round of testing, I found that users didn’t quite have enough ways to filter part cards, even though I had added two additional ways to search and filter parts, an “omni search box” feature and a filter drop-down menu. The problem that users could only filter by what is already in the system, such as state or name/part number. Users didn’t have a way to keep an eye on a particular part. The iteration created was a tagging system.

The tag only does two things on the screen, turn off and on, but for the user, it could do so much more. Having a part that keeps having troubles? Tag it! Have a part you’ve been meaning to edit? Tag it! Have a few parts you wish to filter exclusively? okay, you get it….tag em! This was a simple and very effective way of adding ease of use to the platform, yet not altering the withstanding way of business.

Another iteration made was the functionality of the cards themselves. Initially, the design was to send the user to a page that dealt with the action the user was requesting without any sort of hover over system. The user was hesitant to page hop back and forth, stating that clicking all throughout the app would cut down on productivity. The actions were moved to happen within the part cards, this was done to allow the user to quickly check what they had to do rather than travel to a page to find out. Even though the difference is seconds those seconds add up in a day, and the user’s mindset is not one for wasting time. Making this change added another level of ease of use.


Examples

Final dashboard wireframe.
Final order detail page. Many pages used this layout. Process blurred to keep confidentiality.
Final wireframe for a mock part page.

Summary:

The Omnae platform is soon to be released out of its closed beta and set upon the world it was made for. My work within this project has brought the web app into a new level of usability and connectivity with the user base and backend team. Additionally, the choice to follow google’s material design language allows the Padtech development team to further expand and iterate the platform without an aesthetic sacrifice or designer on hand. This is a great feature for both my client and myself, fo I get to see my work and ideas grow as time goes on. And as for my client, no longer are they limited to the product they are creating and investing so much time into.

This project was a few firsts for me. First project outside of the RED Academy, first paying design job, and the first time I was to create a product of this scale on my own. Although not as I pictured it at the start of the project, I am incredibly proud to have done this product and what lessons I have learned from it. From learning to work alone in a freelance setting, to conducting contract negotiations, I’ve completed a design I am proud to call my own. My work in these two and half weeks changed how I see the common items around me, and how I see myself as a professional.

To know that my design is on its way to affecting the global sourcing industry in a positive manner makes me realise how important design work is. The companies that will use the Omnae platform will work more efficiently and ideally cause a better product to be created. That does not only affect me but the rest of the consumer ecosystem as well. Knowing that may happen gets me even more excited about the wonderful opportunities and products I will create in the future.

Want More?

Visit my portfolio!