---

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:

• In your role and in your department, what’s the nature of your interaction with end users and customers?
• How can User Experience Research & Design help you accomplish your goals?
• How can you and your team help User Experience Research & Design accomplish ours?

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:

• What do all of those different roles mean? What’re the expectations for each level in each role?
• What are the growth ladders and how does one move through them?
• How do the various parts of the business (engineering, product management, customer solutions, education, marketing, sales) interact with the UX team?
• What is Research and how does it work?

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:

• Quarterly, we meet to review/revise our UX Team Charter, which lays out our Mission Statement, our Core Values, and our Short- and Long-term goals. This provides a North Star for the team to center around, helps us resolve conflicts and disagreements when they arise, and ensure our individual efforts are building toward a shared goal.

• Quarterly, we also have some sort of team retreat. This might just be a shared lunch or dinner, a meetup we all attend, or a larger event such as the NYC Pride Parade or a conference. Getting time together outside of the office and outside of the context of work helps build cohesion and a sense of community via shared experiences. Q3’s activity will be spending a day as volunteer dog walkers.

• Monthly, we have a meeting for anyone doing design/research work at 1010 (called 1010Design), which includes our multimedia content designers, our instructional designers, PMs, and anyone else interested. This helps increase transparency as to what we’re working on and provides a platform to share challenges, increasing empathy and cross-team collaboration. It’s also the place where I give updates to the broader community as to what the recent happenings are for the UX team.

• Weekly, we have UX Team Meeting, where we talk about any challenges our team is facing as well as provide updates as to what’s going on at the company at large re: UX. I do this to get us more face time together but also to ensure everyone is on the same page. We also do biweekly retros in this meeting, helping us improve how we work together and identify barriers/inefficiencies. Highlights of this meeting also include our “What Are You Consuming” segment, where we share an interesting/fun article, podcast, TV show, etc.

• Weekly, we also have a Design Critique, in which we bring ideas we’ve been working on to present and to gather feedback on. The sole purpose of critiques is to get feedback from our peers and to increase the quality of our work. This is different from our weekly Design Review, in which we bring “finished” designs to the PMs and engineers on a given work stream for them to review, ask clarifying questions, and push back on anything that might be technically difficult.

• Daily, we currently no longer require a standup. The UX team provides updates asynchronously via Standuply, which are then posted to our channel on Slack for anyone to see. By removing the burden of a set standup time, this increases individual freedom and doesn’t artificially inject a stopping point in one’s focused work.

• Daily, I do ask my team to update any of their current tickets on Jira. Even if it’s just “no updates today”, this creates an audit trail, and it gives anyone at the company the ability to see exactly what state any particular task is in. It makes my life a lot easier when someone asks “hey where are we on ___?”

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 ([hello@bradorego.com](mailto:hello@bradorego.com?Subject=I 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

---

Posted on July 27, 2019 in User Experience
Tags: [organization] [user experience] [leadership] [process] [human-centered design]