A B2B Web Dashboard that allows C.H.I. to get in touch with their dealers, and allows the dealers to build technically complex garage doors, generate a quote and send an order.
C.H.I. Overhead Doors
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of iTexico
C.H.I. Overhead Doors is one of the biggest garage doors manufacturing companies in the USA, but the software they developed for their dealers to send orders was obsolete. The client saw an opportunity not just for update it, but also for transform it into a communication platform so they can increase sales and be closer to their dealers.
My role in this project was as a UX Lead, conducting meetings and interviews with the client, their IT department and some of their dealers and customers. At the same time, I managed the design tasks, delivery quality and a team integrated by 3 designers.
I conducted some interviews with the client, the IT department and some dealers which had a lot of experience with customers. The existing app was obsolete, it was built for Windows 98 and was not suitable for any modern platform. For this project, I created the following documentation:
This was very useful for mapping the scope of this product, some technical details and even for the client to show progress to the stakeholders.
There were some challenges on this project, mostly on the technical side. The original app was not ready for microservices, so the development team had to rebuild everything in the new backend. On the UX side, we had to be sure that the app was able to be displayed from Internet Explorer 9, so we had to use very standard components across all of the app.
On the other side, the client didn’t thought that they would require a CMS to generate all the content that they were planning, so we came up with a simple but effective solution for them: we built our own CMS inside the app and depending on the role, the user was able (or not) to access it.
As we were making progress, we encountered a very big technical challenge that put the project at risk: for the dealers to effectively create an order, they needed to fill a form with almost a hundred inputs. The requirements were clear: the full form must be displayed, because dealers were used to fill them using keyboard shortcuts (which had also to be present). The form on the original app was ridiculously big, so we had to, somehow, port that to the web app.
I spent some weeks trying to understand the logic behind that form. It was so obsolete and technical that even the IT guys from the client didn’t fully understood how it worked. Then, I noticed some patterns as I was getting more familiar with the old app: some of those inputs were disabled, some other were activated and even new components were displayed depending on… something. I eventually found out that all of that behavior was triggered depending on a specific input that the user fills almost at the beginning.
So, the solution for it was to display only the first fields of the form until the user got to that specific input. Once there, depending on what they entered, the rest of the form would be displayed showing only the components needed for that specific input. This allowed the user to focus only on what they needed, and saved a lot of work to the backend server.
The app was deployed on the client’s server, tested on their side with some of their users and then fully implemented. The users loved the new interface which not only allowed them to build and send orders, but also to be in touch with the company. They found out that by being in constant communication with them, they were able to sell more and better.
On the client side, they needed to assemble a team that created the content but the investment was worth it: they increased their sales and the satisfaction rate from their dealers.