Before starting at Tyk as a UX Designer, I thought I was good at questioning. Now, after nearly eight 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 quickly discovered 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 would never 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 to understand something is what will 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 understand 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 change 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?” We can change 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. For example, 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. I often 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 inquisitive, 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 vital 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, which can sometimes lead to breakthroughs that we would have never 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 many people can feel afraid of asking questions and 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 you may have solved much earlier with just a few questions.
Ultimately, understanding the product you’re working on is up to you. However, I think we can all become better designers if we care enough to ask questions and have the desire to learn. In the past few months, I feel like I’ve been able to output better work because I’m more familiar with how our product functions. And there’s also nothing more satisfying than being in a technical discussion and understanding what everyone is talking about!
So, to end things, my challenge is for you to become a question-asking machine too:
