I’ve worked for DealerOn for the last two years. But back in January I started a new role in the organization. The title is UX Business Analyst, and my core responsibility will be to develop a dedicated focus on user experience. The organization has never had one before, and this role change was no accident. I had a firm hand in the development of the position. Now its time to put my money where my mouth is. Over the coming months I will taking this idea and bringing it to life. For now, I will give some background as to how I got here, and how I worked to develop the position.
My experience at USA TODAY
My journey to becoming a UX Business Analyst at DealerOn was not direct or expected. Yet somehow the dots ended up connecting themselves. Before starting my career at DealerOn as a Front-end Web Designer I had the privilege of interning with USA TODAY on their UX Team. I was fresh out of college and happened to have a mutual connection that got me in the door. It was a short 8 week program, but I took the time I had to absorb as I could.
I learned how to design and wireframe in Sketch while assisting my coworkers with the 2016 Election Experience. I also learned how to prepare, proctor, and annotate user testing sessions, including remote testing with participants using Usertesting.com. But perhaps most valuable of all, I learned how a large-scale, well-funded, and fully functioning UX team operated. What I didn’t know at the time was how that experience would impact me more than two years later. That experience gave me the foundation I needed to see what was possible. That became especially helpful walking into a company that had never known a proper UX team before.
The “UX testing guy”
Fast forward two years and three internal positions later (Front-end Web Designer, Project Lead, and Business Analyst), I found myself right back into the mix of UX. Only this time, with a much smaller team, significantly less resources, and starting from scratch. What started as a passing conversation with my manager about my past UX position at USA TODAY, gradually turned into a newly ascribed identity of the “UX testing guy”. While working as a Business Analyst eight months ago, my manager volunteered my services to a team with a product in need of usability testing. Both confused and terrified (1. because I had no idea what I was being asked to test, and 2. because the last time I had run a test was 24 months prior, at the direction of a team lead), I was thrown right into the deep-end. I think the phrase “sink or swim” would apply here.
That first test was a “growing experience” to say the least. Our scrum master booked the rooms and participants, one of our Front-end developers took notes, and I developed the script, ran the tests, and filmed the participants. For a first test crammed into a sprint cycle, we over did it. We had too many participants, asked too many questions, had no clear idea and agreed upon goal of what we were testing, and had no formal process to guide us. Of course we didn’t realize this until we had to annotate the footage and present our findings; which translated into two full days of annotating. Lessons learned for the future:
- Keep it simple
- Create a process to follow
- Clarify the goals
After that I learned about Why You Only Need to Test with 5 Users, developed a repeatable testing protocol, and created testing process documentation. A few months and a few tests later I was beginning to get the hang of it. I found endless resources of online research to guide me, and best of all, I had an environment to try out what I was learning. It was the perfect place the learn. Because I was the closest thing we had to a content expert on UX research in the organization, no one was going to tell me I was doing it wrong, and I could set the tone based on research and practice.
From “no more Material” to a Design System
A few months prior to my implementing user testing into our product development process, the manager and leading force of our Front-end Development team left for a new opportunity. In leaving the company, he also left a vacancy that impacted the team for months after. The team no longer had its leading voice and advocate, leaving the group to pick up the pieces. To his credit, he began developing the foundation of a Design System before he left, basing it on Google’s Material Design built in Vue.js. He starting crafting components and designing the foundation of a future CMS for the organization. However, rather than researching the problems and demonstrating value to the organization beyond the Front-end team, he slapped on Material Design and Vue.js as the answer. Unfortunately, due to his approach and his relationship with leadership, his work and ideas were quickly abandoned in his absence.
Based on my experience as a Business Analyst I was able to see the problems in the organization and took it upon myself to take a deeper look at how a proper Design System would provide benefit. I knew he was on to something, but I also knew that approaching it differently could pose different results. So I started my research by reading Atomic Design by Brad Frost and Invision’s Design Systems Handbook to understand what Design Systems were meant to solve, and how to go about creating one. What I found confirmed that a Design System had the potential to move us in the right direction to solve… :
- Inconsistencies in design across our product portfolio
- Expensive and inefficient product development
- A lack of cultural understanding of the value of UX
All I had to do now was advocate for what I learned, but how was I going to do that when people around me were saying, “if I hear ‘Material Design’ one more time…”? I had to be strategic.
Step 1. Get the team involved
I started by buying Atomic Design and passing it around the Front-end team. They were the easiest to convince because they were already familiar with the concept and were directly impacted by the lack of a tool-kit to build our products. By allowing them to digest and synthesize the value for themselves, I was no longer the only advocate in the organization. The conversations went from “what do we do about this problem?” to “how do we make it happen?”. Standing on a soapbox and doing it all on my own wasn’t going to solve anything, in fact it would have only created more distrust and aversion. Getting the team involved and letting them advocate the value for themselves proved to be the better approach.
Step 2. Document the problem
Next, I conducted a visual inventory of our core CMS to document all of the variation of key components in the design. I based my research on the components found in the Vuetify UI library, as that was what the team had determined would be their framework. I presented my findings to the team, and none of what I found was news to them. They knew the technical debt and they knew the problem; our systems were outdated and built over time with an engineering focus without strategic considerations for user-centered interaction design. In the end, six different variations of a blue button proved to be a more clear summary for removed stakeholders, like Leadership.
Step 3. Getting the organization on board
After listening to peoples pain-points about why past efforts had failed, I learned that the one of the core reasons people had a negative association with Material was that “it didn’t feel like DealerOn”, and they were right. Material was designed by Google for Google, it was not designed with our company in mind. No one had ever made it clear to stakeholders that Material was a framework that we could customize to our needs, and no one had done the research to show what those needs were. By helping people to separate Material from a DealerOn Design System we could begin to make steps in the right direction. With a new group of advocates, and clear visual evidence that there was a problem in need of addressing, we were ready to start changing hearts and minds.
Step 4. Pitching to leadership
Now that I had a team of advocates, research to support the value proposition, and a shifting cultural view of Design Systems, I turned my focus to developing a presentation to leadership. I broke the presentation into a two-fold approach to solving design debt at DealerOn:
- Consistency with a focus on building a DealerOn Design System.
- Usability with a focus on UX testing, planning, and research.
I studied the industry, learning about common deliverables, tooling, roles, responsibilities, expected ROI, and how to solve a need that plenty of others had succeed in. In the end, I had a solid deck and a platform of work and research to support my pitch. So with all that ready, I picked a time to sit down with the VP of Operations, I went for it, and here I am today. A newly assigned UX Business Analyst tasked with implementing UX at DealerOn. Be careful what you ask for I guess, right? I guess we’ll find out!