One day at work, I came up with what I thought was a great idea for the company’s and started working on it for a few weeks. I did my research, prepared my evidence and brought them up during meetings. But I could not move the idea to implementation. There was little momentum and excitement on the project. I felt stagnant.

As I was struggling, my mentor gave me a useful tip when working in a product : think of your conversation with your teammates as a user interview. If you understand their goals and help them achieve it, you are bound to hit your goals along the way too.

“The best kind of design isn’t necessarily an object, a space or a structure: it’s a process — dynamic and adaptable.” — Don Norman

I thought it was a lightbulb moment and started to think about my work differently. Now when I hit a roadblock, I’d take a walk and step back to think about what I do in design that can be applied to working in a product team. Experience definitely helps you draw the connection faster. But if you are someone who, like me, just started out, a list of reminders may help.

Here’s my list of principles to keep in mind when working in a product team.

To functionality… and BEYOND

Let’s first visit the design hierarchy of needs. Functionality is the lowest level in the pyramid. You may not want to stick with a product that works but breaks down sometimes, is unforgiving to errors and is uninspiring.

If you and your colleagues spend 8 hours a day at work, it is an important part of your life that should fulfil your low-level and high-level needs. In team communication, there are a couple of useful things to keep an eye on:

  • User-friendly language should draw a picture and help users wrap their head around an idea quickly. Sometimes you have a very important point to make, but to get it across, it is better to show rather than tell. If hard numbers are not available, I find sharing stories of real, important and struggling users usually works well.
  • Just like how system feedback should be positive, assuring and humanised, micro-interaction with your teammates should too. There are no shortcuts or best practices to this tip rather than making real friends.
  • Inspire and get inspired. I am often surprised by how similar the struggles at work of other teammates are to mine. Being open about the difficulties you faced and how you’ve tried to overcome (even if you failed) may create conversations on how things can be done better.

What is the problem, really?

Users tell you that they want something. Most of the time, there is an underlying, unarticulated need that is waiting to be discovered.

Here are two examples to illustrate:

You share your design with Samantha from the engineering team. There is a mockup and an interactive prototype, but she still wants to have a more detailed list of use cases of your design. There are many dependencies in the system that she has to consider. Every time you talk to each other, there seems to be a new case to consider.

What she actually needs may be something else: She needs to be involved earlier in the design process. If you get a list of dependencies from Samantha and share with her your high-level ideas before doing your design, you may save time for both. You may come up with an idea that is less technically “non-trival” and still meets your goals.

John from the marketing team asks if you can give him a simple design real quick so he can add it to his new blog post and ship it today. He gives you a few suggestions to help you do it faster. You want to make sure the image quality and the company’s branding are not compromised, so you tell him you might take a bit longer.

What both of you needs to do to balance your different goals may be to agree on a set of templates. You may try to understand the different cases where John will need visual assets, take your time to make a design template that you will be happy with. John may give you feedback on whether the templates are usable at all and if it has helped him become more independent from your timeline.

Your teammate is not a persona

So are your users. Personas, however comprehensive, are not a replacement for understanding how your real users behave.

You may find a common thread in your colleagues from a certain profession. But it is dangerous if you develop simplistic stereotypes of how people behave.

Developers are not just a group of people who sit in front of their screens and write elegant code 24/7. Many developers actually like to be involved in the design and decision-making process. Some even have good design sense.

Designers are not people who only push pixels and scribble on post-it notes. Some designers choose the profession because they love seeing ideas coming into existence, whether it is through drawing interfaces, persuading people or doing a bit of coding.

Find out more about what motivates people may lead to some amazing collaborations and initiative projects. For example, a designer in our team is motivated by “influencing people to live well”. He chooses to do that through design … as well as through improv and standup comedy. So he turns our monthly company all-hands into super engaging sharing sessions and motivates everyone to tell their best and most entertaining stories.

“Usability is like love. You have to care, you have to listen, and you have to be willing to change. You’ll make mistakes along the way, but that’s where growth and forgiveness come in.” — Jeffrey Zeldman

Hope this is helpful. See you in the next post!

Source link—-eb297ea1161a—4


Please enter your comment!
Please enter your name here