Building a UX Department from scratch at a 20-year-old Big Data Company

UX@1010's inaugural post, where I cover what I've been working on at 1010data in getting newly minted UX Department up and running.

11 minute read

Originally written for 1010data’s UX Blog

These stories usually start with some sort of “when I first heard about ___”, but in this case, that goes much further back than a) the story usually goes, and b) is really practical. 1010data has been around since 2000 and has gone through tremendous growth and change as an organization since then. Recently, we’ve embarked on a new set of changes.

Document the process

There are two things I hear time and time again when telling friends, family, and colleagues about what I’m doing at 1010:

  1. “that sounds super cool and like a great opportunity”
  2. “you should write about this”

I literally have a post-it note on my desk that says “Document the process” to remind myself to tell the story. This blog is one small, tangible step in that direction.

In February 2019, I joined 1010data to build and lead a UX Department. I was lucky to inherit two excellent designers who were coming up on 2 years into their career, a lot of excitement from the majority of the employees, and eager support from senior leadership. It’s nice to come into something with the wind at your back (believe me; I’ve certainly been in situations where you’re treading uphill, upwind), but it’s still a tall ask. Starting from scratch means we have to define everything, and being a 20-year-old data company means there’s some inertia to overcome. Change management is often the hardest part of any process.

Starting from scratch

When’s the last time someone tasked you with not only defining the structure of your part of the organization and writing all of the job titles and descriptions, but actually defining what it is your department actually does? Sounds fun, doesn’t it? Maybe a little daunting, too? What actually is a User Experience department? What do we do? What do we deliver? How do we do it? How does this fit into what the rest of the company does? How do we interface with the other teams? These are some of the questions we’re continually working through, discussing, and experimenting with.

Luckily, I’d just had many of these conversations at my previous position with Prolific Interactive (who recently joined the We Company). I joined Prolific to help them transition from having a team of Product Designers and a team of UX Designers to having Product Design and User Research. Part of that meant figuring out what to do with the existing team and the existing roles & responsibilities, which, in Prolific’s case, begged the question: how do you define “Design” versus “Research”? What are the core responsibilities and fundamental duties of each expertise?

Design is an exercise of creation. Research is an exercise of discovery. Both involve creative problem solving and both strive to answer questions, but they come at it with different approaches.

The answer (in its current form), based on my experience plus a handful of conversations with peers, mentors, colleagues, and other people outside of the “UX” world, is that Design is about solving problems through a creative endeavor (ideation, iteration, production of assets, etc) whereas Research is about answering questions and uncovering insights (research questions, usage analytics, interviews and observations, etc). Using this as a guide, we set out to redefine what Design and Research meant for Prolific. Transitioning an 8-year-old company and a team of 9 has a unique set of challenges, but here at 1010, we’re starting at the ground level.

Bearing that flag and using it as a guide, the first thing I did when joining 1010 is to have a lot of conversations. Before I joined, UX was poorly defined (the designers I inherited actually had the title “UX Engineer”), and was confined to one new product team. The vast majority of the company had very little idea of what UX was or what it could be, so I set out on an interview tour.

Aside from getting face time with a variety of stakeholders at the company and giving them an overview of my vision for User Experience at 1010, I had three main questions for my interviewees:

When I was going through my vision of UX@1010, I found myself drawing two diagrams on whiteboards repeatedly, which I eventually codified and put on Confluence:

You have a structure, now what?

It’s important to set up the long-term vision of where the team is going and how you should organize yourselves. Not only does it give us consistency and clarity in language, it also sets up aspirational paths for the team (which I’ve learned more about and crystallized my belief in by reading Primed to Perform). But all of this structure by itself doesn’t get us very far. There were a few outstanding questions, notably:

So, of course, we got to work.

What does “getting to work” mean here? A handful of things. I first had to go through 1010’s management training to understand how 1010 structured career trajectory and growth. 1010 has a set template and philosophy about Career Development Plans, however the content of each CDP is up to the team to define themselves. Once I understood that, I set out to investigate what other companies’ job descriptions included, combined that with all of my experience, and started writing CDPs.

I prioritized the titles that we currently had and were working to fill at the department. I took the first pass at all of these and then passed them both to my team and to upper management to review and provide feedback. By coming to consensus and writing down in concrete terms what we thought each role should be, we started to create clarity as to where we could all grow professionally. Goal-setting became more concrete, and conversations in weekly 1:1s with the team shifted from “how am I doing” (which can be hard to answer) to “how can I work on ____” (which is much easier to answer).

Clear, concrete position definitions and expectations made it easy to self-assess strengths versus weaknesses and identify growth opportunities.

Where the rubber meets the road

Structure is one thing, and while it’s important, it doesn’t actually drive results. Your success as a leader is measured both by your ability to generate consensus and motivate your team but also to deliver positive outcomes via leveraging resources. In order to do that, I needed to start implementing repeatable processes, update our tool use, build in methods to ensure quality. I also wanted to get some rituals in place to help build consistency, culture, and help spread the gospel of human-centered design.

One of the first things the team agreed to do is to hold weekly Office Hours. Sure, it might sound like something you grew out of once you left academia, but it’s been an incredibly effective tool to increase exposure to UX across the organization and to support the teams we cannot allocate resources to currently. There’s a great appetite for UX across 1010, so we wanted to do whatever we could to support, encourage, and grow that appetite. We’ve received a ton of positive feedback on those efforts.

Rituals not only help build camaraderie and consistency amongst the team, they also provide a framework and create expectations for team members.

I’ve also added and modified a few daily, weekly, monthly, and quarterly meetings for the team. Yes, it pained me to add regularly scheduled meetings to everyone’s calendar. However, sometimes they make sense and add value. Specifically:

I’ve also worked with the team to develop a few guidelines and standard practices. We have an initial draft of collaboration guides for Design-Engineering and Design-PM, and we’re working on similar guides for Research. We’ve also switched from Sketch to Figma, which has enabled us to build shared libraries (which is crucial for our budding Design System; more on that in a later post), increase collaboration between designers and with engineering, and made it easier to work iteratively given Figma has version control built in.

Many, many times have I heard designers and engineers alike singing Figma’s praises. Gone are the days of “____ has that file on their machine; I don’t have it” or the static comps laying out exact sizing/spacing by the pixel. Engineers can get whatever assets and specifications they need in a live, interactive manner. Product Managers know exactly what state everything is in by looking at the live design (we put the current “finished” version in a Master page) and can leave comments directly on the document. We can also link directly to specific Frames, reducing ambiguity when we’re talking about implementation. We’ll go into further detail on the Sketch-to-Figma switch in a later post as well.

What’s next

We’ve covered a lot of ground in this post already, but there’s so much more. There are many more things I’d like to get off the ground (I haven’t really touched at all on the Research side of the spectrum), but we’ve gotta start somewhere. 1010 recently hired a new VP of Product, so I’m excited to work with them to accelerate the team’s growth and 1010’s shift to being a user-centric, product-focused organization.

We have a lot more work to do and a lot more to cover. Subscribe to this publication to follow along our journey. The plan is to post every other week as we go, and you’ll hear from all different members of the team. Our next post will cover the history of design at 1010data, which we’ll follow with posts about migrating from Sketch to Figma and about the development of Disco, our design system.

And, as always, don’t hesitate to reach out directly to me ([]( read the 1010UX blog and I want to chat)) if you have any questions, comments, suggestions, or just want to talk shop! We’re always looking to collaborate and share ideas.

Originally written for 1010data’s UX Blog

All User Experience posts: