Swapx
Building a global IT asset provisioning platform
Over the course of two years, I designed and developed a robust IT provisioning and scheduling product for a major client of Multiply Technology. We markedly improved the provisioning experience for the client's employees and IT organization. Armed with positive feedback and praise, we successfully won contracts to expand the product to all of the client’s global offices.
Client
Multiply Technology + Fortune 50 client
Roles
UX Designer + Web Developer
Timeline
October 2016 - July 2018
Above: Swapx on desktop.
Context
So many hats
I had the pleasure of being part of a small and mighty team of fewer than 10 people at Multiply Technology. I was the lead developer for our products, and as I developed skills and interest in design, I also took on UX design and visual design responsibilities. My manager supported me with client relationship management, user support, and back-end development…while being the CEO. Start-ups, gotta love ‘em! 🤪
Supercharging a vital client relationship
In 2016, Multiply had budding products centered around IT provisioning solutions for both its internal operations as well as for clients. At the time, Multiply had a promising relationship with a Fortune 50 tech company; this relationship was also Multiply’s largest revenue stream. Hence, the business need was to continue growing that relationship (and revenue) by solving their IT provisioning problems in innovative ways and demonstrating the high return on investment (ROI) that Multiply could offer.
Important note: I’m not at liberty to disclose the client’s identity nor share direct copies of the work that I did. As such, all screens in this case study are re-creations.
Process
Glossary
IT provisioning: The deployment and management of IT assets such as desktop computers, laptops, mobile phones, and other technological paraphernalia.
“Swaps”: Replacing an employee’s device. An employee may need a new device because they were newly hired, they had joined as part of a merger/acquisition, their current device had reached the end of its support period, they had spilled coffee on it, or any number of other reasons.
Tech: The IT technician conducting the swap; employees or contractors of the client.
Employee: The employee whose device is being “swapped”.
Starting off with a glossary? What is this, a fantasy novel?
The problem with swaps
Prior to our intervention, the client’s process for swaps (as still is the case at many large companies) was highly manual and time-consuming. Our initial contract with the client was to serve swaps at the client’s offices in Indianapolis, where Multiply was located.
I started off my research by interviewing stakeholders (managers within the client’s IT organization), interviewing IT techs, surveying employees who had completed recent swaps, and simply sitting in on swap appointments and observing. This was my first-ever foray into user research, and I found that I really enjoyed hearing from users and discovering the problems plaguing their day-to-day work activities.
Above: User flow diagrams pre-intervention.
We also compiled a list of issues and needs faced by all parties, and this informed our initial design proposal.
Designing locally
Once approvals were won (no easy feat, but that’s a different story) and our first contract was signed, we could begin designing and developing a product to elevate the swap experience. Since I had observed that IT techs exclusively completed their work on their laptop and desktop computers, we focused on designing for desktop screen sizes.
For this case study, I'm using the alias Swapx for the name of the product. For this and (story spoiler!) subsequent contracts, we followed the following approximate process:
Above: Process summary.
I collaborated with my manager to outline and design idealized flows for the swaps. To support this, I created user flow diagrams for our proposed solution as well as a basic data model.
Above: User flow diagrams for the proposal.
Above: Basic data model.
With that out of the way, I kicked off development work. I started with the back-end, where we built out databases that integrated and communicated with the client’s IT support case and inventory management systems. After that, I completed front-end web development, building a swap management dashboard (for techs) as well as a swap appointment scheduling page (for employees).
Once front-end development was nearly completed, I conducted multiple rounds of usability testing — internally at first, then with the client. You may have noticed that I didn’t mention any kind of research, prototyping, or testing between the initial stakeholder research and now. Well, that was unwise.
In one instance, I had misunderstood a stakeholder's request to be able to view multiple locations simultaneously to mean that they wanted a dropdown selector, when they meant that they wanted to view multiple tables on the page at the same time. I did not catch the mistake until the stakeholder tested the beta release. Predictably, I had to do a lot of similar bug-fixing and late feature additions to account for these kinds of oversights.
After each release, we monitored performance and user-submitted feedback on our changes. Additionally, I conducted user interviews with affected techs and observed them at work once again. These channels informed further improvements that I would design and develop in the post-release support phase.
Scaling globally
Despite bugs and hiccups along the way, Swapx performed so well in reducing time and frustrations for all stakeholders that we soon entered negotiations to improve it and roll it out to the rest of the client’s North American locations.
I must now abridge my tale, lest the rest of this case study (covering two years of work) grow into a full-length novel. In short, we successfully won contracts to expand Swapx from North America (AMER) globally to the client’s Europe-Middle East (EMEA) and Asia Pacific (APAC) offices. For each expansion, I followed the same general process I outlined above, conducting user research and interviewing stakeholders from a region before developing enhancements to Swapx that adapted it to that region’s specific needs.
AMER expansion: I found that techs in other locations followed a more complex hierarchy, where supervisors could assign swap appointments for their subordinates. Hence, I designed and built an admin section and implemented user roles for the techs, with hierarchical privileges. The techs also requested a custom date ranges.
EMEA expansion: The client’s IT organization followed a unique set-up in this region, where techs in a single office (e.g: Dublin) handled swaps for employees in multiple offices (e.g: London, Amsterdam, etc.). Therefore, I had to introduce yet another layer of complexity: regional/location scopes for techs and showing multiple offices on the dashboard.
APAC expansion: I enjoyed this one the most: Localization! The client’s offices in this region accommodated local languages in addition to English, particularly in Japan. Because of that, I had to redesign the swap appointment scheduling page to support localization. I had the opportunity to interview techs and users located in Japan, and received support in translating content.
By the end of 2018, Swapx was humming along nicely across the globe for our client and its employees. What a journey it was!
Outcomes
A successful partnership
The feedback I collected was extremely positive in every region we expanded to. Techs felt that swaps were much more clear and predictable, and they spent a lot less time on them. Employees felt much more confident and happy with the process. The client noticed, and rewarded us with more work. In addition to the aforementioned regional expansions, we won contracts to grow Swapx to encompass mobile phones, mergers/acquisitions, audits, and more.
All told, the contracts Multiply won across the years totaled in the millions of dollars. This allowed Multiply to grow and expand, and more importantly, the experience and software we developed was used to pursue new clients and improve the IT experience for thousands of users.
Learning the design process
As mentioned above, our process was not perfect. I missed many opportunities to get early feedback and validation from users, particularly before investing time into development. The truth was I just did not know any better. If I took the time to create wireframes and prototypes to test with users, I could’ve saved a lot of time and effort later on. There were multiple unnecessarily stressful periods of time when I had to patch in emergency bug fixes and enhancements that were overlooked.
Throughout my time at Multiply, I built up an enjoyment and interest in speaking with stakeholders and users, as well as obsessing over design systems and UI elements. The lessons above plus this self-discovery process led me to learn about the user experience field. In 2019, I left Multiply to pursue a Master’s degree in user experience, and the rest was history.