Sun 10:53, Amsterdam
Back

24 Things I learned as a Product Designer

Blog post

24 things I learned as a product designer

A year ago I decided to switch from multi-client teams and focus my work to one single client by joining a dedicated product team. Here is what I’ve learned and reflected during those 356 days.

1. Invest time in learning the product

Working with an in-house team that’s dedicated to one single product, means you have to spend some time on-boarding, learning what the product is all about. What is their main business, what is their product matrix, who are the customers, is there a specific business field in which this product or service fits in, who are the main competitors. Asking questions is a must, and by doing your proper research, you will gain confidence and better exposure to your work.

2. Learn the language

Design is such a middle player in the game between business and development. It is crucial to learn the language of your team and the language of the organization. All this knowledge combined with the history of the product and there you have it, a successful starting point for the creation of smooth and silky experiences.

3. Remove the time difference

Teams are shifting, players are changing their positions, the whole product game is super dynamic. It is common for big features and services to take their time in order to be shipped and developed. So often you will work on things that have already been researched on or even partly developed. Expose your work to everyone involved or was involved and you will find so much history behind the tasks you are doing now. This would ideally create a better version of your proposals.

4. Make your designs vulnerable

Design critiques are the ultimate source of inspiration. During them you can see how the design thinking takes place, people get triggered, they start asking questions and ratiocinate around them. So by being part of critique sessions, you are gaining more product knowledge and experience. This is truly inspiring. And remember, have some fun.

5. Learn the codebase

Learn more about the structure and the technologies that the product team is working with. This would give you more insights on possibilities and a better approach to how you can deal with future endeavors.

6. Brainstorm with the Back-end

They are the gatekeepers, they let the data in, they let the information flow. Discuss ideas with them. By having insights on the data structures you are able to predict things better and make way more confident design decisions in the future.

7. Improve with the product

This is probably the best situation you can end up in. You have an already working product, which you can continue improving. You can always test, research and find ways to improve your design skills by using the base of the product. Looking for a new tool? Use the product to test it. I learned Framer by using our npm package of core components and the UI kit from Sketch to adapt the full component range and started prototyping quickly and efficiently. I shared prototypes with my team members and business units, asked for feedback and observed how they respond.

8. Design the full flow, ship only part of it

When a new feature or a proposal for improvement comes in, you should always take a step back. Look this small feature from a bird’s eye view. You can see how it will affect the product’s flow. At some point, the business requested an improvement of a small component which is connecting 4 applications. I took my time to review the whole platform and created a flow, which communicated all the places this component exists and should be re-introduced. That was also a clear indicator where the component should be introduced from scratch.

9. Learn Git & Terminal experience

After all you are not the developer, but you are responsible for the experience, look, and feel. The best starting point to combine your codebase knowledge would be operating with Git and Terminal. That way you can be a vital decision-maker responsible for the precision of how things are implemented.

10. Start shipping production code

Once you get your hands dirty and understand the code, the processes around Git and Terminal, you can start working with them to push some changes and improvements. Most of the time the developers are overwhelmed with functionality solutions and performance issues, so they would appreciate the help seeing some experiences and visual changes getting done.

11. Leave room for your design teammates to grow

The nice part of being in a design team is that your teammates are people just like you. They do have interests and desires to improve as professionals and people. Align those interests with them, be the person showing what is important to you. That way you can collaborate on a completely different level. Some people may be more passionate about the technical part of the design, others prefer to take lead in product meetings and workshops. This is a good stepping stone for a unified and strong design team.

12. Always ask for data

Your ideas and designs would often get crushed by opinions and that is totally fine. We are all people. We experience things in a different way. We as designers sometimes take the shot of introducing something new which triggers a wave of changes. Ask for data, seek for numbers to back everything up, that way you can easily draw a map of where the product is going and what can be measured and improved with the newly introduced change.

13. Be nice, but disagree

We as human beings are vulnerable. Dare to disagree and critique when your gut tells you something is going to impact the team, flow or product. Speak up. In the end we are a team and it matters to help each other, forget the ego and the design-first approach. Everything is design.

14. Inspiration may strike you

No story is well written or told, no task is perfectly documented or prepared, ever! The only way to find things that matter to your work or your team is by constantly asking questions. You will be surprised how often the solution is hidden behind a well-structured question.

15. Conduct interviews

The business can be in a hurry, that is totally fine. They need the time to keep up to the dynamic world and push things for innovation at the same time. There would be a constant push for shipping features. You as a designer have the power to pause things, think about them, split them in small chunks. Leave the biggest questions to your users. Conduct interviews, keep pushing for internal validations, present concepts to stakeholders. Don’t take every decision that’s been made for granted. End-users and customer service are the ones dealing with the solutions created by your team, respect that.

16. Present it with a story

You’ve done your research, you know the product now you should come with a well-prepared story. Even a small design task deserves to be presented with a flow and a prototype. Tell the story of how those small things fit a bigger picture.

17. Leave your tools aside, collaborate

You will be bombarded with cool things. Is this the perfect Sketch plugin or what? Should you use Figma or switch to AdobeXD? Is Zeplin enough, why some prefer Invision? We already have everything set up, why not only prototype with Framer? In the end those are just tools to communicate an idea. Leave them aside, don’t focus only on them. Tools are easy to learn. The collaboration and how you work with your story and team would matter the most in the end.

18. Plan your steps

Sometimes specific things are not on the pipeline, but you can always mention them. Show the impact, if the team and organization are aware of the dependencies and connection between applications and services they would know how to act and plan better.

19. The problem is change, and change is just a tweak

Sometimes you will fall into a hole of denial, the team might disagree, the business might not understand. Re-frame your questions or re-frame your answers.

20. Invest time in your own system

Keep changing the workflow. People would appreciate dedication and understanding. Design is there to help. Keep changing the handover. Maybe try with a screenshot, a branch update, a design system change, a Zeplin comment or a slack message? Different handovers would make the team more aligned, but always with organization’s way of working in mind.

21. Between the business and the development

One of the most challenging parts of being an in-house dedicated designer is that at some point you will become the referee, the judge and the collider between the business and the development. They will communicate through you. Learn that, accept it, understand it and embrace it.

22. Find room to focus

Every product team is dedicated to one goal, to get the job done and to create an amazing journey for the customer/user. But note that every piece of the puzzle requires its own devotion and precision. Prioritize your work and know when you can handle something alone or you need help from someone. Value the time of every team member.

23. Chaos is the only way

We think that chaos should be avoided, but in the end, we as people operate in a chaotic world. We try to bring order and understanding through good communication. The journey is always bumpy, but that is the only way to improve and move forward.

24. Have your notebook

Always go with a notebook to meetings and ceremonies, write it down. There would be a time when someone will say something without even understanding how amazing and brilliant it is. Write it down! Your teammates are the essence of the great product as much as the users.