Design jobs are flooding the tech space with more rigor now than ever before. Companies are hiring designers specializing in interaction, UX, UI, and research to grow their established design teams. But for the majority this is not the case. You will probably at some point be one of the company’s first designer.
I received the first designer role as a new hire fresh out of college. I felt so excited to start designing better experiences in this untapped space, but I soon realized how naive I was.
There was a huge discrepancy between the way development teams work and the way I learned how to design.
When you ask designers about their process, they will probably map out something like this:
However, a product lifecycle might look like this:
This form of Agile development was completely new to me. I had a difficult time understanding it, since I was taught that UX was embedded into the entire development cycle. When these two frameworks merge, problems start to arise.
Designers become silo-ed into the space where they are only responsible for creating beautiful mockups. There is no validation stage to determine whether customers will actually want to use the product. Overall, the product is driven by the business needs, not the user needs.
I found that in order for design and engineering to work happily, the following things had to be done:
- Convince your team that research is vital.
- Host effective meetings driven by actionable insights.
- Design a collaborative and open environment.
Let’s start with the first one:
Convince your team that research is vital
Research is a no-brainer. But sometimes it’s easier said than done. A general rule of thumb to remember is always, always research your user base. Everyone will probably give you the initial “we don’t have time for research” response, but guerrilla research can still serve as a good foundation that you may refer to during any part of the design process.
Guerrilla research may include observations, 1–1 interviews, and usability tests. However, you only need about 3–5 of these to gain actionable insights.
As designers, we need a deep insight into the real problem. We want to pinpoint it quickly so that we don’t end up designing for the wrong thing.
It might be difficult at first to show to your team the validity of user research. The important thing to note is that upper management buy-in is the most effective place to begin. Find the main decision-makers and help them understand that research is valuable. They probably won’t care as much about the actual users as they will about the revenue increase, the cost reduction, and the customer adoption. If you’re having trouble convincing others to conduct research, try to frame its value in their type of language.
Host effective meetings driven by research insights
Now that you have conducted some preliminary research, you probably are wondering whether it will ever see the light of day again. This is the perfect time to present your findings to your team and start creating better experiences driven by the user research.
If meetings mainly consist of decision-makers discussing upcoming features for the following quarter, they are probably due for a restructure. It’s not easy to change the entirety of how meetings are run, especially if everyone is used to a particular order already. But instead of wasting time talking about features that people might not even use, we should be making decisions based off of user research insights. These meetings can be reformatted to help the team brainstorm opportunity areas that are user-driven, not feature-driven.
Be a role model for the change you wish to see.
If you want everyone to be fully-engaged, don’t bring your laptop or other distracting devices into the meeting. Be as active as possible and ask probing questions to get the room comfortable in this space. This type of intentional engagement helps encourage everyone else to think critically and collaborate.
You want to eventually drive the conversation towards sharing your research insights and begin brainstorming ways for how the team can solve the user’s actual problems. As the brainstorming grows to a group effort, you should ensure that the environment is fun and safe for people to voice their opinions and ideas. Throw some wacky ideas out there, and get your team thinking about the “what if’s” and “how might we’s”.
Design a collaborative and open environment
If you work at a company that just wanted designers for product aesthetics, chances are they do not understand how dynamically valuable designers can be. What better way to exemplify your talent than to teach by example!
Understand the development lifecycle
When you’re designing for products, you need to know how to blend your process with development. It took me awhile to understand the current development cycle for my product and how everyone’s roles fit together. The current process rarely allocates time for designers to do anything aside from creating wireframes and mocks. My contribution was limited to designing the final appearance of the product once all the requirements were vetted by the stakeholders.
This process was not going to change itself. I had to find a way to talk with users and validate my designs. So I discussed it in the perspective everyone else understood.
I talked in their language, showing higher execs that user research increased business value because we were building a product that people will use. I rapidly prototyped my ideas and vetted them with the engineers to understand what was possible to build and what was not, so that they knew what to expect.
Once you frame it in a way that others understand, you will start to see that design and engineering actually blend very well together.
Keep your team in the loop
In my company, the designers normally spend the initial sprint (3 weeks) going from research to refining mocks, which would be taken to the next sprint for development. The best way to ensure this smooth transition is to ensure your team understands what you are doing. Normally, I spend a couple days talking to users and developing user journeys. Then I pull out their pain points and turn them into goals that can be aligned with stakeholder requirements.
I also ask the engineers, SMEs, and product owners questions to gain a better understanding of the full spectrum of capabilities and limitations involved in the task.
Whether I’m sharing rough sketches or testing designs, I make sure I am transparent in what I’m doing throughout the whole process. This exchange of information leads to a strengthening of trust within the team. You are establishing close connections with your team just by engaging with them on a daily basis. That trust goes a long way. You are no longer a lone designer when you bridge the gap between the people on your team.
At the end of the day, effective communication is what matters most in order to move designs forward.