Designing for tech you don’t get.
Learning, communicating and creating an impact in a technically challenging space.
Co-written by Julianna Murphy and Mrinali Kamath
The success of products in emerging tech (such as quantum and cloud computing) is based on two things: First, a team of brilliant data scientists, researchers, product managers, business analysts, and developers that strive to make the technology better. Second, the loyal users that feel empowered and productive while using the product. To pull off this second component, designers become a critical asset to the team.
In this article, we will uncover just how important it is for designers to be on teams developing products for emerging tech. Then we will dive into some of the challenges these domains pose to designers, and share some tried and tested strategies for tackling them.
Why should designers be involved?
The tech field in general, and especially newly emerging, highly complex tech, tends to skim over the importance of UX in their products. However, there are concrete reasons to involve designers in the development of these products. Let’s elaborate on that a little, shall we?
Designers serve as the catalyst for innovation: Product and tech innovation can easily become stymied by technical limitations and dependencies. When this happens, design thinking methods and user research can shake things up and create new channels for exploration.
Designers drive usability and adoption: Every team member works towards building a successful product for its user. However, it can be easy to push user needs to the back-burner due to the amount of work and complexity involved to bring technology to life. These things can lead to teams “designing for themselves”. Design research and usability testing is a reminder that “you are not your user”. It helps the teams fail early and learn fast with minimum production effort.
Designers align teams and keep them motivated: Designers can use research methods, visual diagrams, and design thinking methodologies to drive alignment and spark collaboration by getting the team out of their bunkers (both physically and mentally). “Yes, and…” attitudes generated in workshops can create a level playing field that breaks vertical team dynamics and give voices to otherwise untapped ideas and perspectives.
But how can designers make these contributions when the technology in question is beyond their understanding? More so, how can they make their voices heard when the rest of the room is skeptical of the value of design? As designers working in Cloud and Quantum Computing, we live these struggles every day. Over time, these challenges have provided us with opportunities to develop concrete strategies and earn our seat at the decision-making table to make valuable contributions to highly technical teams.
We want you to thrive and flourish in these environments and here’s how.
Build domain knowledge.
The mistake designers do is promise deliverables before understanding the requirements of the business and the complexity of the technology. It’s important that you buy yourself time, scope your learning to the task at hand, and be real with your team that you are new to this space.
If you are a designer who has worked on customer-facing products before you already know how to carry out primary and secondary research. Use those skills and your learning style to get a basic understanding of the technology and dive deeper into organization-specific knowledge from fellow designers.
When working on projects that have multiple people from various departments, it’s important to identify your core team by their role. We use the acronym RACI to remember these categories.
Mapping out your team members with this method helps you identify:
- People who will work with closely (responsible)
- Key decision-makers (accountable)
- Sponsor users and subject matter experts (consulted) and,
- People who would be affected by the project in general (informed).
While working with your core team, identify your allies. Look for the teachers in the group that will explain the difficult concepts to you. The great part about being a designer is that you already know how to ask open-ended questions, the only thing remaining is to not filter questions because you think they are stupid. We’ve seen that answering these seemingly ‘stupid’ questions advances the team to align on fundamental concepts.
Take advantage of the fresh and non-technical perspective you bring to the table, this unique angle to the product is what will help you spot areas of improvement in the user experience and help the team learn as a whole.
Communicate effectively
Another important aspect of being a designer among technical professionals is that you intentionally need to hone your communication skills. This starts with not adding design jargon to conversations and using simple words to explain complex concepts.
Create a shared vocabulary by repeating the words and terms that your team members use. This way you save time on getting everyone on the same page when it comes to definitions and terminology.
Design your development process
Align with your team’s process by asking your teammates about the tasks they are carrying out through the different phases of the project. While working with her team Julianna (co-writer) realized that the design process wasn’t very different from a scientific research process.
Similar to how the scientific method starts with an educated hypothesis, so does the design process start with a problem or assumption to be validated. Both entail research, physical experimentation, and then validation steps (user research and measurements) to either prove or disprove that hypothesis.
Aligning on the process and identifying similarities helps the rest of the team understand why you need to follow the design process instead of questioning the time each phase of the project takes.
Have daily or weekly syncs
Work with your product manager to create weekly (if not daily) syncs. Constantly give small updates to your team instead of keeping them in the dark for weeks and showing them polished screens.
Ask your product manager to give you 10–15 minutes during these syncs and sit with your design team to identify parts of your process you need to present during the sync so that everyone in the meeting can benefit from it. Don’t overshare.
Learn to confront conflict
Handling conflict is a big part of your job as a designer. When you sense a debate that will take up precious time, table the discussion and promise to look into it later. Gather your allies and confront the issue with ‘real talk’. I’d recommend using tactics from the book crucial conversations to confront conflicting opinions. You can also use your skill to visualize the problem and help your teams get an overview of the various parts and the blockers.
Build consensus with workshops
Sometimes the best way to get consensus is by getting all the accountable stakeholders in the same room and having a workshop. This also helps you as a designer to prove your value to the team. While planning workshops we’ve seen both kinds of people: technically knowledgeable people who get excited at the opportunity of working together on design thinking exercises as well as the ones who want to be left alone and want nothing to do with designers.
To address both these types of people you as a designer need to do some ‘pre-alignment’ work. This includes the following:
- Identifying your stakeholders: Using the acronym RACI (explained above), assign different roles to these categories of stakeholders. The accountable stakeholders like executives who have less time should kick off the workshop and motivate the stakeholders who are responsible to work in groups. These responsible stakeholders use the workshop as an opportunity to come up with solutions while consulting sponsor users and subject matter experts. The people who need to be informed are then invited to join the playbacks. By assigning these roles you are taking respecting each individuals time and capacity.
- Send an invitation: Use the acronym (yes we love acronyms!) POWER to help frame the invite.
Purpose (why is this workshop necessary?)
Outcomes (what do we want to achieve?)
What’s in it for them (why should stakeholders attend this workshop?)
Engagement (how are you going to ensure that participants are engaged?)
Roles and responsibilities (who does what?)
If these questions are difficult to answer, reconsider having a workshop. - Share pre-reading material: Additionally, send out documents like reports and statistics as ‘pre-reading’ so everyone comes in with a shared understanding of the problem.
- Pick your words wisely: Sometimes you may want to use the words ‘working session’ instead of a workshop. Proactively go through the activities and see which words you can switch to the ones that are more inviting to a broader audience.
- Pick a place: If you are co-located then get a large room but if you aren’t, use tools like Mural and video conferencing apps.
- Keep sessions short: Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.
After the workshop is over, summarize the key decisions and the next steps. Play it back to all the attendees and the stakeholders that have vested interest in the project.
Advocate for design in a skeptical or uninformed environment
While User-centred Design has all but proliferated most tech spaces, there are still individuals who are skeptical of these methods or have a limited view of what designers can contribute. The “slap some lipstick on a pig” mentality is the most common version of this that we have faced in our career; with fairly well fleshed out prototypes sent down from on high with little margin for change allowed.
Here are some tried and tested strategies that we have observed and applied to earn the trust of our teams and get a seat at the decision-making table:
- Share your process and tools at the right times to make the team aware of the breadth of what designers can do. This is a slow process so be patient.
- Technical individuals love hard facts and research findings. Keep the facts handy to pull up when you can sense that the needs of your users are being de-prioritized. Quotes and numbers are much more likely to get your point across than leading with “I think” or “I’ve heard”. Table the conversation when you need research to back your opinion.
- Whenever possible, try to create a net new prototype based on user needs that have yet to be addressed. This helps your team visualize the solutions you are talking about and energizes them to innovate and push the boundaries of the technology you are working with.
- Prototypes also imbue much less risk than creating net new tech. They can be tested quickly and help fail faster, helping teams refine strategy without slowing momentum. This also helps to mitigate the dead-end situation of “technology in search of an application.”
- Apply design beyond interfaces: Whenever possible (in strategy, scoping, storytelling, goals, team practices) try to show just how adaptable design thinking can be.
- Ask to be part of planning and strategy meetings to have a pulse on changing stakeholder needs and any assumptions that are not being validated.
The key is to start looking at yourself as a product person instead of a designer. Start adopting strategies from places closely related to design like agile methodologies, sales techniques, product management and tweak them to make it work for you and your team.
Lastly, be observant.
Your set of strategies can grow if you observe the successful people in your organization navigate similar challenges as you. Irrespective of their department or skill, these individuals can help you thrive in these environments. Be brave, ask for help, watch yourself flourish and your work evolve.
P.S — Hold on! There’s more where this came from! For our talk this year at SXSW 2020 we will be diving deeper into generating ideas, prototyping and strategizing with technical teams! Check it out > https://schedule.sxsw.com/2020/events/PP94777
