Designing what you don’t know
How creating internal data products helped me evolve as a designer
In my previous job, I worked on a Camera app. Literally anyone with a smartphone was our target user. Being quite familiar with the domain, I could speak the language of the user. Not knowing exactly how the HDR function works, or the technicalities of the zoom function, was never a blocker. Discussing technical limitations with the engineering team was good enough for our team to build concepts. But things changed drastically when I joined the Data team at Shopify as a product designer.
We work on products that solve problems like the “discoverability” of data assets (any data artifact like reports, data tables, etc.) across the organization and simplify building online experiments (such as A/B tests). The goal is to help data scientists and engineers, across all teams, to seamlessly create and execute experiments. To be effective as a designer within the data org, I needed to learn the language of our users (data scientists), make sense of the technical terminology, and understand how data products work to clarify the problems.
The transition — from working on a customer-facing product with seven designers to being the sole designer solving problems for data scientists using internal data tools — has been quite a learning experience. It really helped me evolve as a designer.
Here are some of the differences and what helped me overcome the challenges.
Getting to know the user was not the same
While working on improving the discoverability of data assets, we had to give context on things like dependencies (both upstream and downstream) of reports and schemas for data sets. You might be wondering what this means. I felt exactly the same.
I had no background in data and every conversation with my team included terms I had never heard before. Terms like dependencies, extract, transform, load (ETL), raw data, data lake, Presto, Jupyter, confidence interval, group assignments, grain, and fact tables. Some of these were tools performing tasks I was yet to learn, while others were traditional data concepts. I could not even tell the difference!
Data scientists would mention these terms fairly often (obviously) during conversations or user interviews and I felt like I was in an alien world. It was hard to grasp the full picture of what the data scientists do, let alone comprehend the challenges they face. At times, I really felt like I did not belong.
What helped me feel better:
I knew I needed to make extra efforts to empathize with data scientists. For that, meaningful discussions were important and I had to familiarize myself with the domain. And I needed help.
This is what I told myself:
Confess. Ask (Reach out to the experts). Repeat!
This might seem obvious, but I actually feared hijacking a conversation by asking something seemingly “obvious” to others in a meeting and wasting everybody’s time. I knew that I was new and had to do the extra work. I tried to learn by myself through the documentation, but I realized I could not learn much alone and must seek help.
I finally reached out to the experts on the team. They shared their domain knowledge over dedicated 1-on-1s with me, where we just talked about specifics like how a tool works or what a concept means. I asked for sessions meant only for learning and the team was kind to oblige. After meeting more people, I realized it was not always a one-way knowledge transfer. My work was alien to them as well. I also used these sessions as a chance to share what I do as a designer, which helped set expectations. I am grateful to all those whiteboard sessions (back in the office), the Slack messages/calls, and of course the reading material that helped me engage in conversations with the users in a more meaningful way.
Trying to explore more outside of my domain led me to learn another thing…
Know how much you need to know to be effective
Data can get very interesting, as there’s always new terms or concepts to learn. Learning about one topic would open up many more unfamiliar realms. The sheer complexity of connections between different concepts and tools is quite interesting, but can be distracting. When I needed to know how experiments are actually built in production, I found myself indulging in learning more about concepts like p-values (a “probability value” that helps statistically determine if an experiment hypothesis is correct). I got interested in knowing how it’s calculated, why it’s used, or even how Ronald Fisher came up with it, and wondered how things were done prior to its formulation. Dedicating time to such details was not always necessary and I had to remind myself about my role and purpose on the team. Since it was easy to get distracted, I needed to regulate my investments in unfamiliar concepts.
What helped me focus:
I asked these basic questions:
“How is this going to help add value for the users?”
“Is it going to help me answer what the user is really trying to achieve and where they are blocked?”
This helped me realize that I didn’t really need to know everything. And that I was not expected to know either. But I was expected to build better product experiences and, for that, knowing enough to guide the decision-making process was important. Asking such questions allowed me to be intentional about what I needed to know in depth and what is enough to learn at a basic level.
Designers are naturally curious about everything (and that’s what makes design the natural discipline for us I suppose) but we need to be careful. The sheer magnitude of the unknowns in your domain can get overwhelming and at times distracting or perhaps even demotivating. Reminding yourself about your purpose can help select how much of the unknowns need to be known to help solve product problems as a designer.
Again, it’s ok not to know everything!
It can get lonely…
If you are working on an internal tool, chances are you may be the only designer working on it. Great if you have more designers! I was the only designer working on internal data tools initially, along with four other data developers. As the only one from my discipline, I found it harder to communicate the value of design. It could easily be seen as just building the UI once the features are decided on.
Designing and conducting user interviews, sharing insights, and iterating solutions by oneself can feel lonely. There are always doubts about seemingly unique problems and wondering how others have solved similar issues. You also want deeper discussions on parts you intuitively care about (for example, color schemes) or the right interactions. For non-designers, it could easily “look” better, but you know the possible issues and want to discuss the nuances in greater detail.
What worked for me:
I happened to chat with a designer working on another internal product and she totally resonated with this feeling. We started our own sessions for internal-tools designers (fresh eyes), where we would share context and get feedback on the problems we were working on. Gradually, more internal product designers joined and our group grew to nine designers meeting on a biweekly basis. It’s comforting to have a group where doubts on the tiniest of design details can be discussed and general learning and knowledge on design can be shared.
Speak to other designers. Participate in other teams’ rituals.
At Shopify, we have Sidekick, a bot that helps match you with a different person every week for a casual chat. It’s good to learn what problems other designers are solving and learn from their experience over casual coffee conversations. My lead also helped me get involved in regular discussions and rituals with customer-facing product teams, for a fresh perspective on the different processes or methodologies they’ve used. This gave me the chance to learn from designers at all levels of the organization, from interns to group leads. It’s pleasantly surprising how everybody else is equally curious about your product and eager to learn from your challenges as well.
Share more often. Explain the intent.
I also started discussing my decision-making in greater detail with the team and what problems I’m trying to solve with the designs. This helped open up conversations with the user as a reference and not the technical concerns. This also helped my team understand my role and intentions, and I observed a change in how we communicate. Our conversations began using less technical jargon over time. As I shared more often with the team, their feedback became ever more insightful in helping me improve my work.
Polished designs are not as important as delivering value to the user
Data products can be very technical, with a lot of heavy lifting on the engineering side, and are key to decision-making for all teams. The product experience depends a lot on the accuracy and performance of backend tools. For example, it is critical that the data scientists see correct numbers on the results of an experiment. Unless this is achieved, it does not matter how refined the interface is. For such products, the priority becomes dedicating resources to such problems and enabling the right flow for the user to minimize the possibility of errors. Aesthetics and visual polish, although important, take a secondary role.
Quickly building features — like enabling the data scientists to add more metrics to a running experiment — can be of great value if it reduces their workload by hours. Shipping such features quickly matters more than taking the time to perfect the UI experience.
“Detaching” from the design system is not uncommon
Polaris is Shopify’s design system that helps teams build and improve experiences for merchants and partners, while the data team’s Experiments Platform is a tool meant for data scientists working on internal product teams. I rely heavily on Polaris to build and iterate on solutions quickly, but there are many use cases where I need to deviate.
For example, the Experiments Platform requires viewing data with complex details, while a consumer-facing visualization may be more simplified. Working on an internal tool, I felt less mental friction to “detach” and modify what works best for the users.
Iterating on new concepts felt more flexible, while also adding a chance to contribute improvements or suggestions to the existing design system.
It’s easy to access your users
One of the best things about working on an internal tool is that it’s easy to quickly book time with the target user (your co-workers) and gather feedback. Oftentimes, users reach out with feature requests. This can be hard to cater to if their request is beyond the scope of the product sprint cycle, but it helps to surface any unique cases we might have missed while building the product road map.
Gaining more context on the problem through direct connection with users helps keep them in the loop of my work and allows for faster iterations. Any concerns about a design or problem can be tested and validated quickly as well.
I have enjoyed this transition from working on a customer-facing product to a highly technical internal tool. Adapting to a new environment can be initially overwhelming, but ultimately quite rewarding. It took me a while to get comfortable but, if I were to share some tips with my past self about starting out as the only designer on the team, I would say:
- It’s ok to not know everything, you are not required to. But know enough to unblock your own flow. Be conscious of the input (unfamiliar concepts) of information, it should serve the output (user value for your product).
- Counter imposter syndrome by reaching out to more people. Build your circle. You are not alone, others may also feel the same. Collaborate with members in other teams.
- Ask more questions. There are no stupid questions indeed! No one judges you and everybody is happy to help.
- Share your work more often. Familiarize the team with your work so you can speak the same language.
If you have had a similar experience working on an internal product, navigating through a new domain, or as the only designer on a team, I’d love to hear about it! These situations may not be your ultimate fantasy as a designer, but the unique challenges they present can nevertheless help you grow.
