Growing in your career
I thought about naming the title of this post, “Your path to promotion”. But that is exactly what I have noticed is not constructive when moving froward in your career. If your focus is only around arriving to a higher salary and a higher level you are missing the real purpose. Your first and foremost motivation needs to be growth, learning and trust. With these fundamentals economic and level increase will follow. Here are some areas to focus on when wanting to advance in your career.
1. Focus on your impactful contribution
Make sure that discussions are foremost around the positive impact you have had on your colleagues, the problem space you are working on and the company as a whole. And less about you simply getting a raise. This will set a much more constructive conversation with your leaders and keep you focused on the real reason you would be advancing in your career.
2. Go above and beyond before asking for a promotion/raise
If you are not pushing the boundaries of your responsibilities you are not ready to start talking about advancement. Going above and beyond and possibly stepping outside of your comfort zone can be by doing something that you were not asked or expected to do. It can also be demonstrated by you helping someone else that is in need. When it comes to product design we get a lot of attention for having pixel perfect flashy designs, but remember to dedicate time to the dirty work. Tidy up documentation, mapping states, user journeys and edge cases. Going the extra mile will be noticed.
3. Focus also on the growth of your colleagues and team
How you are doing as an individual contributor is often reflected in how those around you are doing. Since your success depends on the collaboration with others, focus on how you can advance forward together as an integrated group of people. Being a team player and the growth of your team is equally important as your personal growth, they go hand in hand.
4. Gather feedback regularly
“How do you think I did?” - seems like a simple question but it leaves us vulnerable. It is actually a very hard question to ask. It is kind of like public speaking, practice makes perfect. Once you get used to asking for feedback it will get easier and more natural to have these exchanges. Gathering feedback can come in many forms. It is not limited to a 1:1 with your leaders. You have exceptional talent working along side you that can provide you with interesting insights on how to improve your day to day work. If you are not up for asking face to face, consider sending out a survey.
5. Maintain a positive outlook
If you find yourself surrounded by a group of people that focus on what is going wrong and complaining about colleagues, management and processes, try to change the narrative. Focus on opportunities and how you can constructively support your company. This does not mean to fake a positive attitude and pretend that every thing is A OK. If you think that something can be improved (and there is always something to be improved), bring it up. Provide enthusiasm to improve it and be a part of the discussion. This positive, get shit done attitude will be noticed and appreciated by leadership. Lead you on the road to advancement in your career.
The importance of documentation
I’ve noticed a common trend in projects that were executed well. The trend is not connected to the actual implementation of a project, it was directly influenced by the quality and consistency of documentation. You work hard to find the best solution, uncovering insights, really trying to make a difference in the experience but all of this work doesn’t really amount too much with out adequate and consistent documentation. A big mistake is to think that documentation exclusively covers the end result. Instead its value lays in being incremental and should be held at high priority throughout the entire process.
There are three main aspects that contribute to making documentation valuable:
Accessibility. Imagine looking at a data heavy table without any formatting, not knowing where to focus and how to translate the data. When you add elements associated to the data; statuses, trend lines, a photo to accompany names, the comprehension improves dramatically. (Fyi, I have a fascination with data tables). This logic can be easily applied to documentation. Make it accessible by focusing on details that facilitate its legibility and comprehension. Breaking down areas with different statuses, tags, data tables, images, check lists, external links, ect. Whatever artefacts and information you have to track the progression, use it. These details go a long way and will improve the relationship and interaction your stakeholders and colleagues have with the project.
Progression. If you document the beginning and the end, there’s a sea of information missing to connect the dots. Stay consistent with the supportive documentation of a projects progress. This will help the team be able to spot blockers and arrive to a stronger solution.
Collaborative. Bring people in. Make them part of the process of documenting the different phases. Ask them to fill in areas and leve their point of view. Send the documentation to the group, sharing is caring. They will be able to follow and feel appreciated for their contribution.
I have identified three main phases that need to be documented and can be applied to many different areas: product design, communication, ux research, product management ect.
Request. Identify the core needs and pain points before jumping to the solution. This allows for others to get involved and for a controlled planning and proioritization.
Project. Have a source of truth that is the primary collection of all that covers the project. Main information like, motivations, main objectives, who is responsible for what, road map and phases can be stored here. Keep it updated! As the project evolves go back here to fill it up and remind you of why you are doing this in the first place.
Results. Make sure there is an overview that collects and reassumes the outcomes. Especially if the outcomes are located in external formats, use this as a container to sum up the activity. Will be a great point to share with others.
Above are the three main areas to document, but that doesn’t mean you have to stop there. Dig deeper if needed to better organize the process of the project. Best practice to document all phases such as decisions, feedback, meetings, co-designs, interviews, ect. Whatever you have to support your work and push it forward make sure it has the proper visibility. Show it off!
Pay attention to trends in your work process, and create documenting templates around them. This will help you and your team integrate, improve and scale project documentation. Get creative, documentation doesn’t have to be boring!
How to avoid design sitting on a shelf collecting dust
Have you ever spent a lot of time on researching, designing and even documenting fresh designs only to have them never see the light of day? It just sits there on the shelf so to say, “collecting dust”? Well, you are not the only one. It is inevitable and in some ways is part of the creative process but important that it doesn’t become the norm and that it is not weighing down you and your team. This trend can create a sense of disappointment and a lack of trust.
While working through a new design, from conception, throughout ideation and to the hi fidelity design here are five check points to make along the way to avoid design pollution.
1) Make sure it is responding to your product’s vision
This is the first and foremost question that you should be asking yourself when staring in the face of change. If what you are going up against is not completely aligned with your product vision, don’t force it. It is a dangerous cycle that results in the company being misaligned and in turn conveying a confusing message to end users.
Your product vision is the guiding light of what the product wants to achieve. As mentioned in, How to define a product vision the product vision impact goes all the way from product strategy and roadmap to backlog and execution/backlog. It is the foundation that needs to be aligned in all steps of the process.
”The vision also serves as a filter to de-prioritize the things that won’t make a meaningful difference to the value of the product or experience.” - Richard Banfield
2) Make sure it is responding to a user’s need
Just because you think a solution would be better for the product does not mean that it will have a positive impact on the end users. You live and breath this product everyday. Take responsibility for your biases and leave it to the experts and data to validate the impact this change would have.
You can rephrase your thinking from, how this would be good for the product (or feature) to how this would be good for the user. There are many techniques to make sure a user centered design approach is adapted. I would like to stress that it is quite useless if used only by designers. It is something that needs to be diffused through out the company, across various stages of product strategy and delivery.
UCD approach used only by designers is like putting sunscreen only on your nose, in the end you are going to get burned.
3) Make sure all stakeholders are aligned/feasibility
I have mentioned the need to work in a multi disciplinary team: PM, designers, research, web/mobile clients, backend/ai etc. digging deep into solid solutions in my previous post. The risk in not involving all stakeholders from the beginning is arriving far in the design process only to find out it would be too complicated to implement. And boom, you have a design sitting on the shelf collecting dust.
Feasibility is a powerful factor, that must not be taken lightly. In a fast paced product company, even a slight increase in extra time needed to implement can stop the developing of a feature dead in its tracks, placing in a backlog which might as well be called, graveyard.
4) Make sure your team has the capacity to actually implement it
There will always be a lot to do combined with the limitations of time and resources. But if you have arrived this far in passing the three previous check points, the next thing to be done is evaluate who is going to work on it. It can be aligned with the vision, be user centred and feasible but if you don’t have the resources and team to work on it, the shelf is where the design will be going.
This is often the result of having higher priority items to work on and the new design just doesn’t make the cut. Rule is try to avoid producing high level design specs unless you know that there is a dev, ready and waiting to bring it to life.
5) Make sure you have all the necessary design patterns to support it
Congrats after passing all previous check points, you have arrived to the juicy stuff. As you know the product experience needs to be built off a strong foundation of components and interactions. You may arrive to the high fidelity design to realise that you need to create a new component, that something like it doesn’t already exist anywhere in your library.
Now you are presented at a fork in the road: compromise the experience and use something that you already have or introduce a new component? It might be easy to choose the second option but as we know this means increasing development’s effort.
This obstacle will be a lot easier to tackle if from the beginning the multidisciplinary group has been working together from the get go. Rule is don’t introduce new components with out being aligned with the developers. They will be taken by surprise and what they estimated to be only a few days of work has just doubled.
When working in a fast pace environment in a constantly changing digital landscape, finding the right balance between the future and the now is what will help you survive. I don’t want you to think that designers should be completely tied down by the limitations of time and resources. There needs to be a balance between working in sync with the rhythm of the delivery process but also allowing yourself to think ahead and outside of the box. These moments of research and if I may dreaming are fundamental to pushing your experience to the next level.
A good designer is not only a designer
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Working in software companies over the past 10 years I feel as though I am just now really being able to look back and state with confidence, this is what I learned, and hope that it can shed some light on your daily work/life balance. Ten years ago I started off as the only designer in the company I was working at and today have arrived to managing a multifaceted design team of 10 people. Working primarily for startup-ish software companies, my role has never been confined to solely a designer. Looking back I see my contribution more as an integration in a much larger machine, that works well with a strong balance between roles. So let's say that in order to be a strong product designer, you have to step outside of the design role. The foundation of my work is not making an experience look good - it is making it work for the user, taking into consideration factors such as business needs, technical limitations, system coherence, accessibility and market standards. Once these are settled and a balance of inevitable compromise has been made, trust me, it will look good.
The dangers of a feature request
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Often internal feature requests are created by anyone in the company. This request goes beyond the description of the friction found and arrives to a solution.
The solution becomes the focus and you tend to lose site of the the reason behind why it was created in the first place. This is dangerous because the solution is handed over to designers, already decided and planned with an appropriate time box and allocated resources.
So the design starts taking off. Benchmarking, interviews, research, wireframes and then what happens when you realize that the solution is flawed and actually the problem goes much deeper? You are stuck.
This is why feature requests are dangerous. I suggest focusing on the opportunity, and not on the solution until all experts and resources are explored and involved.
Don't limit yourself to a quick fix. You risk to spend a lot of time on something that in the end will need to be worked on again. Give your team the space to explore, it will pay off in the end.
Quality vs Quantity
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
A common theme I have come up against is the balance between quality & quantity.
Doing it the easy way, the fast way, the patch work way is tempting. I mean let’s face it, we live in a lazy society, facilitated by simplified search engines, a full dinner only a click away and algorithms that cater to our every desires.
When up against an ocean of improvements and feature requests, what is better: having less but well done or having more but riddled with weakness? I don’t have the answer. But I do know that the quantity road can not become a pattern.
In finding this balance, you need to have all the possible resources in your court. That means doing your research. Sometimes even having one more conversation to get the full picture does the trick. Don’t stop at the initial task. Dig deeper, reach out to people that you might not have discussions with on a daily basis, ask difficult questions. They hold a plethora of information, that can give you angles you would have never taken into consideration.
Stepping outside your box is where you can find balance.
Five ways to shift your thinking & deliver the most valuable solutions
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
1. Focus on the customer friction, not on the feature
When addressing a change to the product, we often think about the feature that needs to be fixed. Instead, taking a step back and think about it as a solution to fix a users problem. This change in perspective can help arrive to a more valuable and sustainable outcome, that could even go beyond the original feature. Skies the limit.
2. Focus on small iterative solutions, not on large impacts
There is user friction in your product. You collect feedback to better understand what is going on, get all stakeholders involved and the creative juices start flowing. It is exciting to think of big, innovative, impactful solutions that could possibly be just what your end users need. But going all in can be dangerous and not scalable. Instead of going for the whole shabang, break it down and think how you can deliver immediate value. Don't confuse this with not thinking big, just think of it as a way to realistically arrive to those big grandioso ideas.
3. Focus on multidisciplinary teams, not on silos
If you are only brainstorming with others that have your same background and role, you know you are doing something wrong. You are likely going to miss something and arrive to a biased conclusion, only to find yourself having to start at square one because of not taking into consideration an important input or limitation. It can be hard to mix professional points of view between devs, product, designers, AI, sales ect. Everyone has a specific goal but in the end you need to understand that your agenda is the same.
4. Focus on co-creation, not on hand offs
This points ties together with the third point but I think it is important to highlight. The handoff can give you an exciting and important finish line feeling. Like great, now it is your responsibility, I am moving on. But I am going to say it again, this is dangerous. It feeds into the silos method and carves away at the beauty of multidisciplinary teams. Instead of product handing off requirements to designers and designers handing off to developers try putting the focus on collaboratively designing together.
5. Focus on the whole, not on the occurrence
You are churning out iterative ideas, each time getting closer to the strongest solution with hi fidelity design only to realize that somewhere else in the product a similar behavior is experienced completely differently. Remember that features are not stand alone, they are part of a bigger system of events. Providing similar but different expectations in a product conveys mistrust and friction, which can result in your end users going somewhere else and slowing down delivery. If you don't invest in the core foundation, cracks will start to show.