It’s one thing to know the right questions to ask your users, but are you asking questions to fully understand the product you’re working on?
Before starting at Tyk as a UX Designer, I thought I was good at questioning. Now, after nearly 8 months, I feel like a questioning machine. I’m in a unique position where I am definitely not our user and I’ll be the first to admit that I couldn’t tell you all of the ins and outs of our product.
To give some background, Tyk is an API and service management platform and our users are in the Engineer, API Product Owner and Architect spectrum. A spectrum that I am not within. I had a lot of learning ahead of me when I first joined and it’s such a complex beast, that I’m still learning more every day.
Question asking is a crucial skill in my role and I discovered pretty quickly that if I asked no questions, I wasn’t going to get anywhere. Can you imagine a person with minimal technical knowledge restructuring the flow for policy and key creation without asking a single question? Nope! The components within that journey alone are complex and just glazing over them from an outside perspective was never going to solve any problems. Are you asking yourself right now what the heck is a policy or key? If you are then that’s awesome! That curiosity and desire of wanting to understand something is what’s going to make you a better designer.
As I’ve said before, Tyk is complex. I ask questions and learn what I need to know to complete the tasks I’m working on. As that work progresses, new things start coming into play and I expand my knowledge by asking more questions to get an understanding of how the pieces of the puzzle fit together.
If I don’t ask, I’ll never understand, and then I can’t truly add value.
If we go with the policy and key scenario from above, here is an example of how you can dig into your product to get an understanding of how it functions and the value it can provide:
“What is a policy?” It’s used as a template to create API keys — if we make a change in the policy it will affect all keys attached to that policy instead of having to change each key.
“What changes can we make to a policy?” Some of the things we can change include the API access rights, rate limiting, throttling, usage quota and path-based permissions.
“What is rate limiting?” Rate limiting controls the rate at which a request can be sent or received.
“Why do we want to limit the request rate?” Because it can help reduce strain on servers but more importantly it can help prevent malicious attacks.
And there are about a million more questions you could have asked to deep dive further. If you’d stopped after the first question you might not fully grasp how each component of the journey functions, and if this is the case, how would you be able to come up with a revised flow successfully?
I’m lucky in some ways that I am not our user. Many times I could be reading or listening to someone explain an area of our product, and they may as well be speaking in a completely different language. I’m also really curious and this pushes me to ask questions and find out how things work. If you’re a potential user of the product you work on, it can be easier to fall into the trap of making assumptions on how something works. It’s really important to put those assumptions aside and ask those seemingly obvious questions.
Question asking is also a form of problem-solving. When one person asks a question the recipient could know the answer — but it also gets them thinking about the subject and that can sometimes lead to breakthroughs that would otherwise have never been discovered. It also helps everyone learn. I’ve asked questions where someone doesn’t know the answer. They’ll go and figure it out and then come back to me with new knowledge for themselves and me. Win-win.
I know that a lot of people can feel afraid of asking questions, afraid of appearing stupid in front of colleagues. My advice is to be brave. It’s ok to admit that you honestly have no idea what’s going on, your colleagues will appreciate that you care enough to ask and fill those gaps in your knowledge base. There’s nothing worse than not asking because this can cause issues that may have been solved much earlier with just a few questions.
Ultimately, understanding the product you’re working on is up to you. I think we can all become better designers if we care enough to ask the questions and have the desire to learn. In the past few months, I definitely feel like I’ve been able to output better work because I’m equipped with more knowledge of how our product functions. And there’s also nothing more satisfying than being in a technical discussion and understanding what everyone is talking about!