If you're like me and love problem-solving, it's tempting to jump straight into finding solutions. But often, we must slow down and, before finding solutions, find problems. 

Problem-finding leads us to solve the correct problems. As I began my new role, I asked the creative director if I could spend the first few weeks conducting research to learn about the environment, people and pain points. 

I've always been relatively intuitive, quickly perceiving what was happening in the immediate and broader contexts. Over the past ten years, though, I've really grown to love research. I have both learner and analytical in my top 10 StrengthsFinder strengths, and getting to do user research leverages these strengths.

This post if part of a Creative Scrum series where we explore the how to apply agile for creative teams.

Who's the user?

Having spent the previous five years designing experiences for high school and college students, I had developed a tight user focus. 

Our team had implemented significant user-focused change powered by surveys, interviews, focus groups, marketing research and user testing. Those experiences were products, and we had a clear set of users.

When designing organizational systems, the question, "who is the user?" can become more complicated than it usually is with products. In the system, there are a lot of users. 

We had the creatives, which could easily segment into videographers and graphic designers, each with their own pain points and goals. We had the clients who requested work, the stakeholders they represented, and higher-level leaders who wanted to know what was happening. There were also partnering teams, like marketing and communication, who we collaborated with but were outside the creative department. 

When we narrow our focus to one set of people, we risk truncating the “customer base.”

I included all of these users in my research, primarily focusing on the creatives and clients. I chose those two because they had the most interactions and were the closest to where value was being created. 

Partnering teams came in third for this same reason of being a critical part of value creation. Stakeholders and leaders rounded things out. They are an essential audience but are less complex and frequent in their interactions with the system I was evaluating.

Interviews

Interviews were the primary method for my research. I chose interviews for two reasons:

1. Interviews provide excellent qualitative data.
2. Interviews helped me build relationships with people.

I began with a few more extended unscripted interviews with the creative director and previous production lead.

I wanted to understand the goals and how things currently worked and felt. This process helped me get oriented and identify goals for my research and the future system. 

A key quote I got from the creative director was, "I wanted clients to tell others, 'C1M (the creative department) is a joy to work with.'" I also saw how the current system exasperated our production team and creatives. 

Trust and empathy will pay off in the short and long term.

These insights helped me frame who I talked to and what questions I asked.

Moving to more structured interviews, I created two questionnaires, one for internal to C1M and one for those external. I kept the questions open-ended while still ensuring I got a good feel for their user journeys. 

In our world of digital distraction, pen and paper cultivate a sense of being more present in the conversation than where there is a screen between you.

I mostly followed the order on the questionnaire but also flexed as the conversations naturally progressed. You can see the questions I asked.

Internal Questionnaire.

1. Tell me about your role.
2. Describe what you do in an average week.
3. Describe your interactions with other C1M staff.
4. Describe your interactions with clients/partners.
5. Describe how you get assigned work.
6. How would you describe your goal for the work you're assigned?
7. Take me through your workflow on a project.
8. Explain how this workflow fits in the larger C1M workflow.
9. What other C1M processes influence your work?
10. How is what you do different than what other C1M creatives do?
11. What are some tricks you've learned to get work done?
12. Describe some friction/pain points in your job.
13. What contributes to these pain points?
14. How do you deal with them?
15. How would you measure the effectiveness of the assets you deliver?
16. If you could change 1-3 things about how C1M operates, what would it be?
17. Anything else you would like to share?

External Questionnaire

1. What is your role?
2. How do you interface with C1M?
3. Describe the projects you've requested C1M partnership on.
4. How many requests have you made in the past 12 months? What were they for?
5. Is there a cycle to your requests? If so, describe.
6. Describe the process leading up to engaging with C1M.
7. Describe the process for submitting a request to C1M.
8. Describe the interaction with C1M between requesting work and receiving assets.
9. Describe the process of receiving the assets.
10. Describe the process of feedback/review/follow-up after assets are delivered.
11. How would you measure the effectiveness of the assets you received from C1M?
12. How would you measure the effectiveness of your projects?
13. Think about a past project with C1M. If you could go back and change one thing, what would it be? Why?
14. Anything else you would like to share?

I could usually get an interview done in about 30 minutes, but I often ended up using an hour because of the value of building relationships. I printed out the worksheets and took notes by hand. 

I find that in our world of digital distraction, pen and paper cultivate a sense of being more present in the conversation than where there is a screen between you. Oddly enough, this still seems true even when many of my interviews with through a video call. Handwritten notes also let me capture observations in a non-linear way that is sometimes difficult with a keyboard.

Organizing the Data

After a batch of interviews, I would take a few and process them using the following steps:

1. Reread the notes for familiarity if I hadn't done the interview that day.
2. Digitize quotes and observations by putting them on a digital sticky note.
3. Synthesizing the sticky notes by organizing them into groups.

I used a tool called Miro for this. It's a digital whiteboard and probably my favorite collaborative tool for teams, whether distributed or co-located. 

The groupings of the sticky notes evolved a bit throughout the process as new trends emerged from the data. I tagged each sticky with a label for which category of user (creative, studio-lead, client, partner...). This gave context to the comment with enough anonymity that I could transparently share the board with anyone. 

Problem-finding leads us to solve the correct problems

As with any time you collect feedback, there were hard things for people to read. I found my role often was to give encouragement, context and hope to those reading through all the notes. In the end, the creative department’s leadership team identified some key areas to improve upon.

Time with people

People don’t operate in isolation. They are part of a more extensive system. And systems are usually more complex than we initially perceive. I want to reiterate some important considerations to make if you are designing multi-team systems:

1. There is a more complex set of users.
2. You're probably going to be working with these people in the new system.

Interactions take two.

It’s popular when designing products to relentlessly focus on the customer. There’s a good reason for this. They are who you are trying to solve problems for and deliver value to.

Systems, however, are composed of people and interactions. When we narrow our focus to one set of people, we risk truncating the “customer base.”

In the system, there are a lot of users

When designing creative Scrum, I had to take into consideration the clients, the stakeholders, the partners, the creative teams, and the leadership. Each group wasn’t just a key customer. If I ignored any of them, I wouldn’t lose a portion of the system; I’d lose the whole thing. 

This is a lesson I learned the hard way from years of designing in-person experiences and taking a nearly exclusive focus on the guests while marginalizing the hosts. 

Users are people too.

I’m trying to stay off the soapbox, but I really don’t like the term user. It's a very transactional and flat representation of a person.

You may be an outside consultant, but you'll likely be around for a while. Make a long-term investment in building relationships as you go through the process. Trust and empathy will pay off in the short and long term.

‍