This post originally appeared on the Connected blog.
As a product builder, it is rare to design for yourself. Sometimes this means you’re designing for the type of people you know, but in extreme situations, you’ll have zero context from your own life, and the rest of the team is in the same position.
In these moments, it’s important to remember that having no personal context for a project is okay. The good thing about our modern world is that we’ve figured out a process for almost anything. On a recent project, I found myself having to leverage the experience of others. Faced with the task of building products for musicians (something I sadly am not) I had to rely heavily on my design approach. This article is a guide for building niche products that you may never have thought about.
It’s more to do with your process than your background
Don’t lean on yourself for answers if you aren’t the type of person who will be using the product.
My team and I were working with a client to build a mobile app to accompany the latest generation of professional speakers.
The app we planned to build was a subset of an established product. Since the who, what, and why were defined, the engagement was labeled as a delivery project. At Connected, this means that the client came to us with a clear idea on who the user was, what they used the app for, and why users saw value in the app; hence, their expectation was for us to deliver on their brief and create production-ready assets that could be shipped to the market.
With the idea, user group, and use cases all figured out, doesn’t that save me (a designer) a ton of work?
My initial expectation when I heard that I was being brought onto a delivery project was that I’ll be diving straight into designs. Now, looking back I realize that would have been a disaster! If I had done that, I would have based many of my decisions on assumptions, or on my own preferences. I wasn’t a musician, so why would I design an app for musicians around my own preferences? It didn’t feel right.
I would like to point out that it can be a bonus if the members of the team also have knowledge of who they’re building for or share a mutual background with the end users. A diverse team of people with different backgrounds and understanding of people’s needs is critical. But that’s not always the reality and to create something new, it’s important to have people on your team that aren’t necessarily the user. In my case, I held no mutual ground with the end users. Yet it didn’t lower the quality of our work because in reality it is less of a background-fit placement, and more to do with a process-fit. The question builders have to ask themselves is: Will I use the right process to get the job done?
Always include discovery in your process
Ongoing research is important and there’s always room for it.
As a designer, even if the client and stakeholders know the product path that they are heading down, you need to do your homework and make sure you have all the information and context you need to get the job done properly.
It is our job as designers to accept the responsibility that comes with being the person who understands best what the product is going to be like when the users interact with it. You are the one that will make all types of decisions across the app—answering questions like: “Does this function deserve real estate on the main page?” Or answering minor behavioral questions from the developers that can make or break the product experience. It is therefore crucial to have the right context and remove any biases or assumptions in order to make informed decisions.
On the speaker app project, as I began to think about the task flows, I felt as if I had hit a dead-end. I was incapable of landing on design decisions. And the reason why was simple: I wasn’t the end user and I didn’t understand their context. I found myself asking myself “How do musicians set up for a performance?” In reality, the question was the answer to the problem. I needed to know those answers. Understanding the end users routine to set up their equipment before a performance, was the key to structuring the information architecture and designing the layout of each screen.
I took this question, and many others, and created a guide. I gathered ten participants around me that fit the user profile and conducted 1:1 interviews. The findings I gathered from the user interviews aided me in creating design principles that kept me on track for who I was designing for.
So let’s say, one of the design principles was to give users quick control and visibility over their system when performing. Based on this design principle and my understanding of the users’ workflow, before, during, and after a performance, I was able to arrive at a solution as to where to place the functions.
With this principle, I was aware that the main screen had to prioritize the primary functions that are necessary during a performance, and was clearly displayed in one spot for quick access. Once I spoke to a handful of users and understood what they needed to set up their performance, versus what they use in-flight, I was able to categorize the functions.
Don’t listen to everyone if they aren’t the target users
The skill is only listening to the people who matter.
You’ll come to a point in your project where the work you’ve done has shaped into an artifact that you can share with people and have them interact with it. People can be anyone from your client, project stakeholders, members of a design crit, or colleagues who stop by your desk.
Unlike testing a product with participants from a user-testing session, you haven’t gone through a screening, so not everybody you speak to will actually use the product. Hence, you’ll have to carefully pick and choose all the opinions you hear, and block the subjective opinions that can potentially have you iterate from misleading data. After all, you’ve come a long way from getting to know the users who will have this product and have made specific design considerations for them.
Let’s circle back to my recent experience. The product I was designing for was not targeted to the masses but was made for a latent user group. The main function of the mobile app did not use a typical interaction gesture that a general person would expect. Instead of using a slide bar interaction, I opted for a dial feature. The reason behind my decision was to follow the users’ industry standard for interacting with this function. I initially found it strange to interact with as well, but after understanding the reasons why this gesture was normal to a certain crowd of people, it made a lot of sense to me.
The problem with this decision was that most of the people who got to play with the app weren’t musicians, meaning they didn’t know how to use the main function. I got all kinds of confused expressions and responses like, “How do you use this thing?” At first, it made me second-guess my decision. However, I ended up agreeing with the 10% of people who interacted with the product—the musicians who intuitively understood the functionality. The majority was not the factor I used to keep me assured, it was listening to the voices that mattered because they would be the ones who would actually use the product.
