Designer interview: Mariana Barros - Pipedrive
Opened this issue · 15 comments
- Mentoring
Hello Mariana. Can you introduce yourself and talk a bit about your background and what you do?
Hey Pedro! 👋
Let's start with the now, currently I'm a product designer @ Pipedrive, and a very happy designer with all I have been learning the past few years. I started with a graphic designer background from college and soon I discovered the wonders of frontend development in Rupeal - SWAT team forever! 💪 Cutting to the chase, when we not only deliver the visual but also you build it, that's the best way for you to"debug" your design and every step of your users flow. SWAT was my home for 5 years and there I could grow to become aware of this, of how important it is for us designers to be closer to the "making" of our screens. Other than this, I'm a dog lover, a foodie and a person who truly believes one day can make a change or at least start it with the help of design (Guess I love what I do as well 😄 ).
What does a product designer do? What are your responsibilities?
We’re like bone and flesh with our PM’s and research team. We always start our projects/missions taking deep dives into research together. We believe that learning the habits of our users to learn about their struggles, needs, and motivations makes a right base to our ideation. With this in mind we start to determine requirements, articulate the user needs and translate them into concepts (interaction models, user flows, wireframes, prototypes (yes...we test every phase with internal and external user so assumptions are not welcomed)…). Since Pipedrive is a “mature” product, It’s also the product designer role to ensure design consistency across the app and collaborate together to constantly refine Pipedrive’s language. We also work close to the engineering team developing the feature we’re working on so we can deal with technical constraints as part of the inicial path, as a specification and not as hard challenge to our designs in the end that can compromise the user's global experience.
Can you elaborate on what's the process from gathering ideas to having deliverables?
We work on a "mission" base premise. These mission’s outcome usually are PoC or MVP’s to gather real feedback and validade our hypothesis. It all starts with the collection of feedback/requests/complaints from users given to the sales team or our customer support team. With this info, PM’s fill in a list an prioritises according to user/business value.
At the phase the design team comes along and starts working on the problem the user is having throw thorough research, interviews and surveys with the help of the research team, documenting it’s need so a mission can start - there is an actual problem to solve.
In the design team we start by creating task flows and diagrams to understand and map a way to solve it within the app, we validate it with CS and sales to check if the use cases given can be “fixed” with this approach.
With a map to guide us understanding how to move inside the app and it’s necessary action, it’s time to build some low fi prototype with some wireframes, testing them with internal users and the with the help of the research team for external users - iterate on it until we reach a good success rate (ex. 80% of users can complete the tasks given) and start with the hi-fi mockups repeating the process. At this phase the dev team lead usually participates and gives his inputs regarding technological constraints so the design team know exactly what it’s or not possible to deliver in this mission regarding time. Missions are projects for 1 month.
After all the testes, the deliverables (hi fi mockups and prototype so the devs have vision on the interaction expected) are handle to the engineering team to start implementing it. Design finishes documenting the testing phase and by creating a new script and survey to test and measure the mission success when it goes life...and sometimes helping on the final tests to the feature - bug hunting.
How do you measure the mission's success? You talked about a script and a survey. Can you elaborate? And if a mission failed, what's next?
What if a mission failed, what's next? Let’s start we this, its easy, there are no fails only learnings we can take from experience. This is the main idea behind this, not deliver fast but test fast, validate fast. There is always something we can take from a mission that is proven not to be useful or necessary as we thought, at least we cross a path and ship to a new one repeating this process.
The success is defined in the begging of a mission and ends after we analyse the beta testers feedback. In the beginning, the team (PM, Dev’s and design) sit together and discuss the global goal - can be revenue, reduce churn, increase conversion, bug fixing, tech improvements, you name it. The fine tune of the goals starts to be seen on the task flow we design and on requests and suggestions during the interviews, with that we assemble the tasks we’ll be requesting users to do on the prototype and later with the real deal feature and our beta testers.
That selected group of beta testers also provide us feedback, and that feedback combined with the performance of our prototypes (by performance I mean users actually complete the tasks hassle free, and we set the minimum goal is 80% of the users doing it) we have collected ideas, suggestions, improvements that can lead to a follow up mission to continue iterating on this launched feature.
That seems like a really interesting process. :) Going back to the product designer role: what's the difference from a junior product designer and a senior one?
Junior designers it's just a name, here everyone has the trust and freedom to do things by themselves, to propose, there is a big awareness of responsibility and our methods and validation processes with real users ensure the junior designers (kinda all the designers) that they will have "accurate" findings and end up with a good solution. Senior designers are like a shadow, they are always by their side, mentoring and following them whenever they ask or is necessary, and I really mean shadow because they're not the hands on the project, but work like a conscience that you can discuss and brainstorm with you to open your mind to new ideas and approaches. Senior designers usually work on the methods and processes for the team, for example our design system, reviewing features and aligning the design patterns (they deliver and present to your team a report with their findings), and even how to make a big team cohesive, close and aware of what is being done.
What's a design system? And what design patterns do you believe to be fundamental?
Well, a design system is a collection of repeatable components and a set of styling standards to guide the designers trough their usage, behaviour and how to assemble those little pieces together in an app. Imagine Lego pieces that can be assembled in a lot of different ways, but even if they are consistent with the app style, doesn’t mean the results will be coherence. Documentation and standards are what separate a pattern library from a true design system and here lays the value of it. Regarding patterns, they'll always depend on your company's needs, so start with a visual audit of your screens and I guess we can all think of color, typography, sizing and spacing, error and validations, grids, iconography and tone and voice as necessary components to build your visual design language. After this I'll recommend you to create a UI library, of the possible combinations and behaviours...and never ever forget to document what each component is and when to use it. Documentation and standards always - remember the difference between pattern libraries and a system, that is a living entity, is iterative and a single source of truth to use in any moment.
The work you do will be picked up by engineers. It may influence frontenders, backenders, QAs, etc. How to deal with conflicts and what tips can you have to have everyone getting along?
I believe this will be my shortest answer of all :) There is only a conflict when you forget about collaborative work. On Pipedrive and on my previous experiences, I always made the effort to include the dev's and pm's during my design processes. This way they're on the same page, they understand my methodologies, my way of thinking and nourish it with their feedback along the way feeling that we all share ownership, thing that we actually do. When running into a problem or restrictions in the project/feature, we run into it together, and since we're all with the same pace and on the same page it's a lot easier to work around it it both fronts, design and development.
It's always easy to comment on the designer's work. We may not like some button position or it's colour. What tips can you give to properly handle this kind of feedback? Specially if coming from someone with authority?