Projeto Livro

Sabrina Silva “Two of the most important characteristics of good design are discoverability and understanding.”

Donald A. Norman

expe riên cias C R I A N D O

Cases, dicas e ideias que vão te ajudar no início da sua carreira em UX.

expe riĂŞn cias

expe riên cias C R I A N D O

Cases, dicas e ideias que vão te judar no início da sua carreira em UX.

Sabrina Silva

Copyright © 2020 by Sabrina Silva TÍTULO Experiências: Cases, dicas e ideias que vão te judar no início da sua carreira em UX. PREPARAÇÃO Sabrina Silva REVISÃO Sabrina Silva DESIGN DE CAPA Sabrina Silva ILUSTRAÇÕES Humaaans.com

CIP - BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ Silva, Sabrina Experiências: Cases, dicas e ideias que vão te judar no início da sua carreira em UX / Sabrina Silva -- 1. ed. -- Porto Alegre: Instrínseca, 2020.

66 p: il. ; 19 cm.

1. Design 2. Produtos digitais 3. Crescimento pessoal CDD: 658.314 CDU: 658.31042

[2020] Todos os direitos desta edição reservados á: Editora Intrínseca Ltda.

Rua Marquês de São Vicente, 99, 3º andar 22451-041 - Gávea Rio de Janeiro - RJ Tel./Fax: (21) 3206-7400 www.intrinseca.com.br

S U M Ă R I O

8

P A R T E

1

O começo 28

P A R T E

2

Pratica e conhecimento 44

P A R T E

3

Mantenha-se aprendendo

P A R T E

1

O comeรงo

Avoiding UX learning burnout Or, how to calm the f — — down.

Since writing about rounding out your UX skills, I’ve seen a lot of stuff on t’internet about overwhelm and burn out in UX because there’s so darn much to learn.

The journey of UX learning Here is a typical user journey…

1. Someone mentions some new prototyping software 2. You Google it 3. You watch a video 4. A comment on the video says “you should also try X software” 5. You end up on a Reddit about “UXers should be able to code” 6. Someone you respect on Twitter is talking about some new type of research you’ve never done 7. Your Whatsapp group pings with some new thing someone has pushed live H Locke UX Director @ Ogilvy. (Opinions mine, not theirs etc.). I design things, I study humans and I like to teach.

10

8. You get an email from Dribbbbble with a load of new animation UI 9. Your boss asks you if you know anything about X method 10. Your head explodes.

Some home truths First truth — Hard things are hard It’s true! There’s a lot to learn in UX. Sorry, hard things are hard. Even being a specialist in one or a few areas takes effort, study and practice.

Second truth — You don’t have to learn all of it Unless you intend to be a UX team of one person in a company of 500,000+ you’re not going to need to be great at everything. (Also, don’t take that job. Sounds dreadful).

Third truth — Someone will always be “better” than you Whatever you do, whatever you learn, it is unlikely that you will be literally the best in the entire world.

And someone will always ask “can you do X?” because either: a) They are a potential employer or PM trying to understand the limits of your genius. b) They are another UXer who is insecure and needs to diminish you to make themselves feel better. They probably also have a very small..

Sharpie.

Follow your own path 11

Here’s a little plan of action to get you through it.

1. Decide what flavour of UXer you want to be — Go back and do the skills matrix and plan your own training and development 2. Create a sensible, realistic training plan with defined topics, resources (that you have scoped in advance and that you will limit yourself to) and time to study.

3. Execute. Do not deviate. If interesting new stuff comes to your attention, add it to your backlog for much later.

4. Review progress periodically. i.e. Monthly reviews conducted by yourself or with one trusted mentor. Don’t weigh yourself everyday to see if the needle has moved.

5. Ignore others who try and tell you that you should be doing something else.

If you know where you’re going, and you have a map, then you’re not going to listen to the suggestions of a raging toothless madman on the side of the road.

Feel calmer? Good.

Above all, have a plan and execute it with focused determination. Aim to fulfil your own expectations of yourself, not others.

The entire industry is totally baffled by job titles and skill sets anyway.

Make your own version of what a UXer looks like. Just be valuable.

12

How anyone can develop a rounded UX skill set Welcome to the 360° matrix

Anyone who has worked with me will have heard me bang on about what I call a 360.

What is a 360?

A 360 is a UXer who has moved outside of one core capability — UX Design, UX Research, UX Strategy, IA, UI and so forth — and has trained themselves, or gained experience, in other areas. They can face into a project from any angle; 360°.

Of course this is not essential in order to work in UX, and specialists are extremely valuable on specialist tasks or highly complex projects.

However being a 360, if you so choose, makes you more valuable to an employer, to the rest of your team or as a freelancer — because you can take on more projects and deliver credible and in many cases, excellent results.

How do you get there?

H Locke UX Director @ Ogilvy. (Opinions mine, not theirs etc.). I design things, I study humans and I like to teach.

13

It’s hard work to become one and it’s hard work to train one. But as a hiring manager, you won’t be able to buy them in unless you have All The Money. And as a UXer, why wouldn’t you want to get better at your craft and make All The Money.

Here’s how to round out your UX skill set — without going back to University.

1. Create a skills matrix Create a chart of all the skills to reflect what you see existing in your UX ecosystem. You can see the one that I made above, but yours might be more dev focused, or more agile focused, or more UI/creative focused. Just remember to map out all the skills you see around you — not just the ones you do every day.

You can do this with pen, or whiteboard or software of your choice.

It really doesn’t matter.

You’re welcome to use mine as a baseline if you get stuck.

Make a list of all the skills you think apply or could apply to your UX world. Then perform a card sort, and create a hierarchy or taxonomy (yes, you are doing Information Architecture now. See, I told you it was important). Then turn it into a chart, or what I call, the matrix.

2. Identify where you want to be Imagine where you want to be on that skills matrix. It’s ok if the answer is “all of it”. Ambition and passion is good.

14

3. Grade yourself Use a traffic light system, or code 1–3 (keep it tight, no wiggle room) which reflects your CURRENT ability for each skill in your matrix. Judge your own level by your own standards, or have a line manager or respected peer help you. (If you are male, be more critical of yourself — if you are female, be more generous. Evidence says you need to.)

4. Do a gap analysis of your team or peers Now do the same for people on your team. Be careful not to let your bias come in here. Again, use a line manager or colleague to help you — you are not critiquing them, you are assessing where your own opportunities lie to learn and grow.

5. Prioritise your first set of target skills Take the gap between where you are and where you want to be, and take the gaps of knowledge in your team and work out which incremental skills on the matrix. Now you are going to choose

A) Low hanging fruit — 1-2 skills which: • Will take you in the right direction towards your overarching goal • Will complement your existing skills • Will be most likely to generate on-the-job opportunities to practice what you learn in theory

15

• Have others on the team already got, so that they could support your learning

B) Harder to reach — 1 skill which: • Does not already exist on your team • Has an opportunity to add value to a current or future project • Has a tangible output you can show the rest of your team • Will stretch you outside of your current skill set.

Example: I am a researcher. Therefore I will develop: A1 — Strategic skills to design relevant methodologies across the whole project, to support the sales/stakeholder team B1 — My understanding of conversational design and start building prototypes to show the team.

If you are super geeky, you can plan activities and subjects you intend to study into some kind of calendar. This ensures that you are accountable for your own progress and aware that time is slipping by.

6. Identify the best tools to help you learn Once you have your list of target skills, start looking for tools that can help you learn. For each subject matter there are different courses, websites and articles available — many for free. There are also nice 16

people on twitter and linked in who might let you buy them a (virtual) coffee for a (remote) opportunity to pick their brains.

And as for books, fortunately past H has already provided you with a very long list of books by subject. You’re welcome.

7. Study your ass off This is the bad news guys, you still have to insert the information into your brain, and find ways to practice until you gain a certain level of competence. Once again, hard things are hard.

8. Track your progress Now this is super important — you need to track your progress. Not just that you are studying, but also whether you are getting practice and whether you are turning those traffic lights from red to amber to green.

You can only judge your progress by your own standards, unless you’re lucky enough to have a mentor supporting you.

I recommend for each skill you tick off yourself when you have: • Consumed and read the theory (at some point, stop) • Practiced the task once • Practiced the task twice • Done it live on a project (that someone has paid for and signed off)

17

O design do dia a dia — Donald A. Norman Resumo do livro “The Design of Everyday Things”.

Este é um compilado super resumido de algumas teorias apresentadas no livro de Don Norman. Norman é co-fundador da Norman/Nielsen Group, uma famosa empresa do Jakob Nielsen, considerado o guru da usabilidade.

Filosofia para os designers • Não culpe as pessoas quando elas não usarem seus produtos corretamente.

• Tome as dificuldades como significantes de como melhorar o produto.

• Substitua as mensagens de erros eletrônicas e forneça ajuda e orientação.

• Possibilite resolver problemas diretamente das mensagens.

• Suponha que o que as pessoas fizeram esteja parcialmente correto; se for inadequado, forneça orientação para corrigir o

Laís Lara Vacco Product Designer | Mindfulness | Empathy | Philosophy | WFPB diet | Arts | My Linkedin: http://bit.ly/2D9lqF2 18

problema e seguir em frente.

• Pense positivamente, por si e pelas pessoas com quem interage.

“Uma das minhas regras auto-impostas é: “Não critique, a menos que você possa fazer melhor”.

Tente entender como o design defeituoso aconteceu: tente determinar como poderia ter sido feito de outra maneira. Pensar nas causas e possíveis correções ao design inadequado deve fazer com que você aprecie melhor o design.”

Don Norman.

Duas das características mais importantes do bom design: Descoberta: é possível descobrir quais ações são possíveis e onde e como executá-las?

Compreensão: o que tudo significa? Como o produto deve ser usado? O que todos os diferentes controles e configurações significam?

Objetivo da experiência do usuário Fazer com que as coisas (produtos físicos ou virtuais) funcionem como as pessoas esperam que elas funcionem.

Você provavelmente já passou por essas dificuldades 19

• Fogão: qual acendedor é referente a qual boca?

• Despertador: o botão da função soneca é o mesmo que desliga ele?

• Chuveiro: será que vou me queimar se girar esse registro ou vai sair água gelada?

Lembre-se: os produtos deveriam ser projetados seguindo a mente do usuário.

Como fazer isso?

Você pode fazer isso, entendendo como pessoas e as máquinas funcionam, unindo a mente humana com a tecnologia, diminuindo o abismo entre ambas.

Transmitindo o conhecimento necessário O conhecimento pode vir de dois lugares: do mundo e da cabeça do usuário.

Do mundo: Explicitamente — quando pegamos o telefone e em uma ligação ele indica: — “digite nove e o número que deseja”.

Implicitamente: quando pegamos o telefone e vem o “tuuuu”, sabemos que a linha está disponível para discar.

Da cabeça do usuário: 20

O mapa mental (referências ou modelo mental) que cada pessoa tem. Elas esperam saber como utilizar os objetos segundo seus modelos mentais.

Um bom design se utiliza dos dois conhecimentos (da cabeça do usuário e do mundo) e não faz com que um conhecimento interfira no outro. O design não poderia entrar em conflito com o que o usuário já possui (modelo implícito) como conhecimento.

Muitas vezes os designers acreditam que o usuário possui a mesma mentalidade que eles, supondo que eles sabem como utilizar um produto. Em geral isso não acontece e o usuário não deveria ter que aprender como aquilo funciona.

O objeto deveria ser um modelo que segue o padrão que o usuário espera: experiência do usuário.

Simplificando Se você tem que explicar muito o passo a passo de como utilizar um dispositivo, então ele foi mal desenhado.

A mente é muito limitada para lembrar ou decorar atividades, por isso a solução é simplificar o máximo possível.

Dicas: • Faça um design simples e intuitivo; • Traga o invisível para o visível. Forneça feedbacks para o usuário saber o que fazer sem precisar decorar; 21

• Automatize funções e dê opção de escolha para o usuário: se ele prefere manual/automático; •Mude a tarefa tornando-a mais simples.

Ex.: Relógio analógico não é intuitivo, digital é. Velcros são mais práticos do que laços em tênis.

Ensinando e mostrando o status Um exemplo disso seria o refrigerador que está derretendo o sorvete.

O usuário deveria saber de forma simples como diminuir a temperatura e saber se ela está funcionando (esfriando ou esquentando e em quanto).

O sorvete não deveria virar uma pedra de tão gelado e nem seguir derretendo.

Mostre para o usuário as consequências das suas ações e dê feeedback.

Mapeando os modelos mentais As pessoas naturalmente constroem mapas mentais de como fazer as atividades.

Quando pensar em produzir/desenhar (design) um produto, procure mapear corretamente seguindo o mapa mental do usuário.

22

Exemplo do mapa mental do usuário (o que ele espera que aconteça): • Girar o volante do carro para a direita e a roda girar na mesma direção; • Apertar para cima sugere aumentar o volume do som.

Usando limitadores Quando se trata de design, os limites são bons. Em vez de um manual de instruções complicado, faça o produto ter seus limites que tornem as atividades óbvias.

Exemplos de design limitadores: Limite físico: O lego é um ótimo exemplo. Para montar o policial em uma moto, ele fornece 10 peças e a criança consegue encaixá-las sem manual pois a peça possui seu padrão com limites e só permite o encaixe em uma peça.

Ela não conseguiria encaixar uma cabeça no lugar da roda pois não entraria.

Limite semântico: A criança deveria saber que uma cabeça não vai no lugar de uma roda.

Limites culturais: 23

No caso do lego, os limites culturais determinam a localização das luzes do objeto. No caso do carro de polícia, a luz vermelha fica localizada no topo.

Os limites culturais tendem a mudar com o tempo.

Esperando por erros Um bom design procura prevenir os erros. Para os que não forem previstos, torne a experiência natural e não tão complicada para o usuário.

Você precisa saber como os usuários irão errar e auxiliá-los em duas coisas: evitar o erro e se possível, revertê-lo sem muitos danos.

Os erros podem ser divididos em dois tipos principais: escorregões e erros mais complexos.

Erros escorregões Os escorregões são quando a pessoa queria fazer uma ação, mas acabou fazendo outra.

Exemplos de erros escorregões: • A pessoa coloca leite no café e depois coloca a xícara de café na geladeira. Foi uma ação correta aplicada ao objeto errado.

• Esquece de desligar o acendedor do fogão depois de fazer o jantar.

24

Como prevenir: • Pegue o que você acha que pode confundir o usuário e faça de forma completamente oposta a isso.

• Mostre uma mensagem ou feedback explicando em que aquela ação resultará.

Erros mais complexos Geralmente são ações conscientes e envolvem um objetivo errado, devido a alguns fatores. Neste caso a ação executada corresponde ao plano, mas o plano é que está errado.

Exemplos de erros: • Furar o farol vermelho no trânsito porque está atrasado para uma reunião.

• O peso de algo é calculado em libras em vez de quilogramas.

• Um mecânico falhou ao concluir a solução de problemas por distração.

Esses erros são mais difíceis de serem identificados e prevenidos.

Exemplos do que poderia ser feito para tentar prevenir: • Entender a situação; • Guiar ao máximo e manter o estado da situação coerente e fácil de ser interpretado (idealmente com imagens); 25

Desenvolver sistemas inteligentes, como a inteligência artificial para tomada de decisões e resolução de problemas; • Criar checklists; • Reportar os erros.

“Em vez de estigmatizar aqueles que admitem erros, devemos agradecer àqueles que o fazem e incentivar o feedback. Precisamos facilitar a denúncia de erros, pois o objetivo não é punir, mas determinar como ocorreu e mudar as coisas para que não ocorra novamente.”

Don Norman

Padronizando Os padrões facilitam a utilização dos objetos.

Exemplos: os designers poderiam mudar a rotação do relógio, mas como se tornou um padrão universal o “sentido horário” é mais fácil para as pessoas seguirem isso.

Para se fixar um padrão pode levar muitos anos e algumas empresas adotam padrões muito cedo, retardando o desenvolvimento do produto. Mas o padrão é uma forma importante de como auxiliar o usuário.

26

Design importa mais do que você imagina Um bom design importa e vai muito além das interfaces digitais.

Ele está nos objetos e nas experiências do dia a dia. Um mal design gera má qualidade de vida, faz com que as pessoas se sintam frustradas e desmotivadas por não conseguirem realizar as tarefas que desejam.

27

P A R T E

2

Prรกtica & Conhecimento

Optimizing the design process Creating a venue for innovation and collaboration.

One of the designers on our team decided to keep a diary to track how her time is typically spent on a project. At first glance, it screams “I have too many meetings!”, but when you dive a bit deeper, it reveals that a bulk of her time is spent, not on the actual design, but on shareouts, alignment, re-alignment, and coordination activities. Not only are these activities typically unaccounted for when we plan a project, but they tend to occur at late, costly stages of the design cycle.

Her time-log highlighted three key challenges of any project: • Maintaining alignment across a project while moving the project forward • Avoiding churn on a design during costly stages of our product development • Managing feedback, while also giving breathing room for innovation These challenges are even more important now that we shift to longer-term strategies for remote teams. We no longer have the luxury of collaborating or meeting casually in hallways or at a coworker’s

Emma Salom Sr. Program Manager with Adobe Design, based out of San Jose, Ca. 30

desk. We have to make space for these types of conversations, without overburdening the system with too many meetings.

This article describes how we enhanced our collaboration model to help tackle these challenges.

Re-evaluating our Collaboration Model Our team supports multiple surfaces and platforms, which means we also have multiple stakeholders, product partners, development teams, and timelines.

“Unless our engagement model scales, we will constantly find ourselves having to roadshow concepts, re-align on ideas, or deal with late feedback.�

What if we take a step back and examine how we collaborate as a team? Designers are collaborative by nature, they are used to design critiques, iterations, and receiving feedback. However, the way we collaborate with our design partners is oftentimes very different from how we collaborate with our product and development partners.

Product partners are oftentimes treated like clients and engaged with formal touchpoints. Requirements are left at our door, we go into a design safe space, and then return after a set amount of time to present the work to them.

31

“We collaborate like product vendors instead of product partners.”

The Opportunity: Cross-Functional Jams We needed a way to collaborate with our product partners early and often. We also needed a way to communicate how much feedback we could accommodate, depending on the maturity of a design.

“Design, content strategy, research, development, and product committed to meeting regularly. We called it our cross-functional “jam.”

How is this meeting unique?

Unlike traditional cross-functional meetings that focus on the delivery of features, these “jams” also hold space for design and research to collaborate with product and development on ideas. Some ideas are just concepts, some are more evolved, and the rest are requirements that are being tracked against a timeline or release.

An infographic depicting how feeback decreases and fidelity increases as a seed becomes a seedling and then a tree

32

Communicating Ideas (illustrations by @crossfold)

Communicating the Maturity of an Idea In these jams, we use a garden analogy when referencing the stage of an idea. When we present an idea to the team, we always reference what stage it is at using our garden analogy.

Seeds

Seeds are new ideas, thought bubbles, inspiration, or just wild “what if� ideas. Most seeds originate from research learnings, stakeholders, or feedback from development. But, in theory, they can come from anywhere inspiration strikes.

33

• Fidelity of design: Low Sometimes they are just sketches on a notepad or bullet points in a presentation.

• Amount of feedback accepted: High Feedback at this stage lets us know if our approach solves our users’ problems. Some seeds will need research, others will need to be user-tested. We may even find that other groups are nurturing the same seeds and collaboration will be ideal.

• Alignment needs Before an idea becomes a seedling, stakeholders agree that this solves a user or business need and that they align with the overall direction of the idea.

Seedlings

Seedlings are seeds that have stakeholder alignment. Seedlings are ready to be shared with our development team for scoping and sizing.

During this phase, a seedling is usually committed to a roadmap or timeline.

34

• Fidelity of design: Medium-High Enough for our development partners to start scoping.

• Amount of feedback accepted: Medium Feedback usually revolves around experience interactions and technical feasibility.

• Alignment needs Before an idea becomes a tree, stakeholders still need to agree with the direction, even after edge cases and technical constraints have been accounted for in the design.

Trees

Trees are designs that are being worked on with development.

Development has reviewed and scoped the design at the seedling stage and is now starting to work with the designer on implementation.

• Fidelity of designs: High Detailed designs that are ready for hand-off to development. They should be 80%+ complete.

• Amount of feedback accepted 35

Only blocking feedback can be accepted. Any additional feedback can be filed as an improvement or debt against a subsequent release (if applicable).

• Alignment needs Misalignment at this stage can result in redesigns and costly slips in the schedule. With this new framework, you should encounter less blocking feedback on a Tree.

Sample Meeting Format The following is a sample format of a jam.

• Duration: 60 minutes • Frequency: Weekly •Regular attendees: Leads from program, design, research, content strategy, and product management. Stakeholders and development leads are invited in as needed.

• Agenda is collected and curated by meeting facilitator beforehand A portion of our time is spent discussing the status and latest on Trees. We tend to go through these items quickly as other meetings tackle those. A bulk of the time in a jam should be spent on seeds and seedlings.

•Artifacts: It is important to keep an archive of the jams. We maintain an internal webpage for jams that document: what was presented and its stage (seed/seedling/tree), attendees, actions, and a recording of the jam.

36

Key Takeaways from this Framework • Include product partners early and often — By including product partners as a consistent part of our design process, it becomes much easier to get buy-in on an idea, maintain alignment throughout the design process, and course-correct when needed. Yes, this can result in frequent updates to the designs, but it ensures we are aligned with our product partners at every stage in the design process and helps avoid costly pivots later in the design process.

• Establish a language for soliciting feedback — The garden analogy provides an approachable and memorable way to solicit feedback. By labeling something as a seedling or tree, it quickly communicates how mature the idea is and how much feedback we’re able to accommodate. This makes our design process much more efficient and minimizes costly churn.

• Provide a venue for cross-functional collaboration — The consistency/predictability of this meeting reduces the meeting load for a project; it reduces the need for one-off meetings and “roadshow” type shareouts as you can invite guests into the jam to review work in progress. This collaboration model also cultivates innovation. By introducing the concept of “seeds”, we manage expectations, and collaborators feel more open to sharing loose concepts.

37

Designing at Google: 10 things I know to be true Reflecting on my first year at Google.

Google wasn’t exactly known for their design a decade ago. A lot has changed since then.

I joined Google last year on the week of their 20th birthday. I was curious to see how design evolved for such an unconventional company.

Looking back at the past year, here are 10 things I learned that I hope will help you with your design journey.

1. Design for everyone Focus on the user and all else will follow. From the very first day of orientation, speakers instilled into us to respect the user. With nine products that have more than one billion users, designing for everyone took on a whole new meaning. The smallest design changes could affect millions of people.

At my previous companies, accessibility and internationalization were an afterthought. At Google, our designs need to be inclusive and we need to think about supporting the next billion users.

Kenny Chen Designer @Google. Curates @uxdesignweekly.

38

I’ve become a better designer by focusing on providing a great experience for as many people as possible.

2. Develop influence, not authority Before Google, I was the head of UX for a midsize, public company.

When I joined the search giant, I had the same title as hundreds of other designers and no direct reports. Here’s the thing — you don’t need a fancy title or to manage a team to be a design leader.

Google is very much a relationship-based organization where influence is everything. Building strong partnerships with product managers, UX researchers, and engineers are essential. That’s been true for every company I’ve designed at, but especially here.

How do you build influence? Start building trust by asking questions, listening, and taking a personal interest. Once you’ve got the team’s trust, inspire others on your vision by showing how it aligns with the team’s goals.

3. Get feedback early and often Google’s design community is huge and everyone wants to be helpful. It’s not uncommon for someone to throw a quick chat on your calendar to meet or get advice. Chances are pretty good that someone has already dealt with a similar problem in the past.

As the new designer on the team, take advantage of your status by asking lots of questions. You don’t know what you don’t know. There’s a lot of history and design decisions that went into a product that you’ll need to uncover. Don’t be afraid to show unfinished work to 39

get early feedback. By the time I go into a design review, I’ve already had a chance to address any concerns.

4. Leave your ego at the door Ego gets in the way of good design. During my interview, I asked what traits successful designers at Google have. One that I heard many times was not having an ego. While a healthy dose of confidence is good, don’t aspire to be the smartest person in the room. We don’t always have all the answers and that’s okay.

Good ideas can come from anyone. There have been many times where someone else has come up with a different way to solve a problem. By remaining open-minded, we collaborated on a better solution for the user. Stay humble by reminding yourself who you are designing for and empathize with them.

5. Imposter syndrome is real There’s always that voice in the back of your head questioning if you belong. At a company the size of Google, that feeling multiplied. I worried I wouldn’t be successful despite designing many products people love.

I’ve come to realize that everyone experiences some form of imposter syndrome. No matter how much you know, there’s always more to learn. I’ve learned to embrace the feeling. Now, when I have even the slightest of doubts, I’ll look back at my past year of achievements and know that I belong.

40

6. Invest in yourself A man designing on a whiteboard

“The most important investment you can make is in yourself.”

Warren Buffett

One thing I appreciate about Google is the many learning opportunities available. I’ve taken classes on everything from storytelling to running design sprints. Once a year, Google has an internal UX conference. Designers from all over Google come together to give inspiring talks and workshops.

Not only have I learned from others but I’ve tried to give back to the culture of learning. I give talks on design, mentor others, and teach courses. To become the best version of yourself, embrace the uncomfortable. Do things that scare you. That’s when real growth happens.

7. Focus on your strengths How do you excel among other super talented designers across the organization? Develop and optimize your strengths. Using your strengths results in higher levels of positivity and engagement. It also leads to sustained peak performance.

During performance review time, everyone has to list one thing you do really well. One of my strengths is analyzing data to find patterns and 41

organize ideas. I try to get data whenever I want to make an informed design decision. I’ve learned to focus on my strengths and to look for opportunities to use them in my career.

8. People over technology In a lot of ways, working at Google is like working at a well-funded startup. Each team has different processes and tools. While debating between Sketch and Figma is fun, tools change all the time.

Technology is always changing and there are new design trends each year.

The one thing that stays consistent is people. We like to think we are all unique but the way human’s think, feel, and act is predictable.

Human’s are creatures of habit and don’t change as fast. Understand how to work with your teammates, their motivations, and goals. It’s much more important than learning new tools.

9. Understand the business Throughout my career, I’m amazed by how many people don’t understand the business they work for. Everything from the products, users, goals, and how they make money.

As designers, advocating for the user is still the number one priority.

Knowing the business makes it easier to convince cross-functional partners to invest in your solutions.

Google is big on OKR’s (objectives and key results). When presenting designs, I make sure to tie them back to the company, team, or 42

product goals. Linking design outcomes to the greater company strategy reinforce the importance of design.

10. The journey makes us appreciate the destination “Fall down seven times, stand up eight” Japanese Proverb

Getting into Google was a dream come true but it didn’t come easy, which made me appreciate it even more. For the first seven years after college, I applied to Google almost every year and only got as far as a phone screen. A few years later, I managed to pass the initial screenings. I was flown to the Googleplex for a full day of interviews.

I didn’t get in.

Between all the rejections, I continued to learn new things and work on my craft. A recruiter reached out almost five years later. After going through the process again, I finally got an offer.

Everyone’s journey is different. There will be ups and downs. If you put in the work, you can achieve anything but the journey never ends. There will be new goals and dreams. I’ve learned so much in my career and the past year at Google but there is so much more to learn. I can’t wait to see where my journey takes me next.

43

P A R T E

3

Mantenha-se aprendendo

Don’t make me think: Designing products that eliminate question marks Revisiting 7 principles from Steve Krug’s common sense approach to web and mobile usability.

The Design of Everyday Things, Don Norman gave us the famous example of the intended simplicity of doors. It’s likely that many of us are familiar with this analogy, as most introductions to user experience rarely miss an opportunity to name drop the concept.

In a nutshell: Doors are simple, and whenever I interact with one in the real world I should understand how to use it. I turn knobs, I push plates, I pull or slide handles depending on the door’s design. And any failure in this logic equals a failure in the design, or implementation.

The root point being: Doors should not require instructions. Bad interactions, in both physical and virtual worlds, create obstacles between a person and a thing—between a user and an interface— like a push door that you keep mistakenly pulling by the handle.

The question you have to ask about any design is: what if this was a door?

H Locke UX Director @ Ogilvy. (Opinions mine, not theirs etc.). I design things, I study humans and I like to teach.

46

The unfortunate reality is: We’re surrounded by Norman doors.

The world is full of poor design; full of products that are confusing or difficult to use. Products that make us think too hard about the goals we’re trying to accomplish. So much so that many people, when faced with a product or feature they can’t understand, assume user error. “I must not be smart enough to figure this out” being their final thought before deleting that app or venturing to the next relevant Google search result.

This year marks the 20th anniversary of another seminal work on usability: Steve Krug’s Don’t Make Me Think. Originally published in 2000, with a revised edition released in 2014 to address mobile usability, Don’t Make Me Think is still considered by many to be an essential resource on user experience design thinking.

A well-worn copy of Don’t Make Me Think

47

In his book, Krug laid out many valuable—and simple—principles on human-computer interaction that, after 20 years, are still very relevant for designing products that people easily understand; that don’t make them think. We often attribute this continued relevance to a famous quote by Jakob Nielsen: “The human brain’s capacity doesn’t change from one year to the next, so the insights from studying human behavior have a very long shelf life. What was difficult for users twenty years ago continues to be difficult today.”

So, on the 20th anniversary of Don’t Make Me Think, let’s take a look at some of those lasting thoughts—quoted directly from the book—and consider how they can be applied to products we build today, and even the next 20 years:

1. “Your goal should be for each page or screen to be self-evident, so that just by looking at it the average user can say ‘I get it.’”

Just like Don Norman and his doors, Krug argued function over form as crucial to designs that have high levels of recognition and easeof-use. In reality this concept could, and should, be applied to any product that a person interacts with; everything from applications and mobile devices to consumer kitchen products. As the saying goes: Clarity is key.

To achieve clarity we not only have to follow established patterns and conventions, but we often have to exercise restraint. Designs that add visual noise cause users to spend too much time thinking about the wrong things, leading to “mental chatter.” Krug argued that, as designers, it’s our job to “get rid of the question marks,” so that anyone,

48

regardless of their technical capability or interest in the subject of the product, can approach it with confidence and say “I get it.”

2. “If something requires a large investment of time—or looks like it will—it’s less likely to be used.”

There’s an abundance of psychological principles behind this one, so let’s break a few of those down.

Fitts’ Law, for example—which was introduced in 1954 to calculate the performance of assembly line workers—states that the bigger the object, the faster you can point to it. Seems like this was probably a short study. Nevertheless, it teaches us that the quicker a user can accomplish an action (like clicking a button) the faster they are going to feel gratified, which aids in building trust with users.

Hick’s Law dictates that the greater number of choices, the longer it takes to make a decision. Simpler solutions bring more satisfaction.

As designers of products we have to simplify choices by breaking complex tasks into smaller, more manageable steps so that users don’t feel overwhelmed. But we have to be careful to not take simplicity too far.

The concept behind Tesler’s Law is that every application must have an inherent amount of irreducible complexity (i.e. there’s a limit to how much you can simplify a process before the burden of that complexity is transferred elsewhere). When designing products it’s imperative that we simplify with every design iteration, but be careful not to transfer too much of that burden onto the system or the development team.

49

3. “Get rid of half of the words on each page, then get rid of half of what’s left.”

Most people don’t read a screen, they scan it—because they want to stay on task and do it quickly. We should treat most use cases as a mission that can be accomplished in a short amount of time, and limiting the amount of text on a screen is essential to this goal.

It’s also important that we develop clear visual hierarchies for both words and objects on a screen that create noticeable relationships that can be scanned quickly. Copy and hierarchical organization go hand-in-hand. The best designs are well-organized, to the point, and clearly highlight the information that’s most important to the user’s journey.

The Second World War Encyclopedia by tubik

4. “As a user, I should never have to devote a millisecond of thought to whether things are clickable — or not.”

50

According to Krug, “another needless source of question marks over people’s heads is links and buttons that aren’t obviously clickable.”

Users will often overlook subtle clues, so help them out by clearly indicating the elements they can interact with.

5. “The main thing you need to know about instructions is that no one is going to read them.”

Product-based interactions, like doors, shouldn’t need instructions.

It’s important that we aim for the self-explanatory, because no one has time to learn your product. Companies like Ikea and Lego excel at accessible, visual instructions that bridge age and language barriers, and serve as a model for how design can guide the user through task completion.

On necessary instructions Krug added, “Your objective should always be to eliminate instructions entirely by making everything self-explanatory, or as close to it as possible. When instructions are absolutely necessary, cut them back to a bare minimum.”

If instructions become necessary: Show don’t tell. Allow your users to learn by doing, while guiding with prompts.

6. “Occasionally, time spent reinventing the wheel results in a revolutionary new rolling device. But usually it just amounts to time spent reinventing the wheel.”

With something like 95% of all data that exists in the world being generated in the last few years, that doesn’t leave much possibility for you to come up with something “new.” We benefit from sticking to 51

expectations for interface design and functionality, so that we build products that work the way people expect them to work.

Think if it this way: Many interfaces that share similar objectives and use cases—such as messaging apps like Viber, WhatsApp, and Facebook Messenger—employ familiarity to drive usability. By staying within existing conventions for mobile text messaging—a left-to-right format that most people understand—new chat-based tools will experience a higher level of adoption because users aren’t faced with learning something new.

7. “The only way to find out if it really works is to test it.”

And we’re definitely not talking about focus groups. No matter the level of fidelity or resources available to you, sit down with another human being and watch them use your product. End users should always be the primary validation point for any design. When you test regularly, you’re provided with fresh perspectives on your work.

According to Krug, “If you want a great site, you’ve got to test. After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore. You know too much. The only way to find out if it really works is to test it.”

I also like to look at this one from another angle: It’s important that we design features that allow users to test them out without fear of breaking something, or unknowingly performing a destructive act.

With the right error proofing, products should allow users to explore and learn fearlessly.

52

Usability is about people, not technology. To truly create usable products that people understand, we have to know how people use and understand things. To quote Krug’s book one final time: “A person of average (or even below average) ability and experience can figure out how to use the thing to accomplish something without it being more trouble than it’s worth. Take my word for it: It’s really that simple.”

53

Os UX designers são os próximos Product Managers e eu explico o porquê

Um título chamativo, como este, vem sempre com um texto polêmico, mas este artigo vem com um outro propósito e explicarei o porque.

Como passei por isso, posso falar com propriedade e UX designers, está na hora de desapegar de seu sketch/figma e olhar realmente seu produto e entregá-lo com maestria de ponta a ponta!

“Product management is about insights and judgment, both of which require a sharp mind. Hard work is also necessary, but for this job, it is not sufficient.”

Marty Cagan, Inspired: How To Create Products Customers Love

A menção ao livro do Marty Cagan, cabeceira de cama de muitos líderes, é justamente para mostrar que existe uma correlação entre Product Managers e UX Designers.

O Product Manager é a pessoa que é focada em ajudar o time/ empresa a entregar o produto certo para seus usuários. E o UX Henrique Bustamante Product thinker, designer de berço e apaixonado pela família, nas horas vagas sempre estuda como um produto deve ser melhorado.

54

Designer é a pessoa que resolve problemas afim de entregar o melhor produto com a melhor experiência para seus usuários.

Mas esta coincidência é o ponto chave para eu falar um pouco mais sobre os papéis e defender a tese que os UX Designers serão (e já são) os próximos Product Managers das empresas.

O PM, abreviação de Product Manager, possui algumas funções como: • olhar benchmarks; • entender o mercado do seu produto e clientes; pain points; • oportunidades através de pesquisas; • roadmap médio/longo prazo; visão do cliente atrelado ao seu produto; pensar na estratégia do produto; • análise de dados qualitativos e quantitativos.

Já o UXer, abreviação de UX Designer, possui algumas funções como: • ver aspectos do produto; • ux research (dados qualitativos e quantitativos); • testes de usabilidade; • Protótipos; • benchmarks; • roadmap curto/ médio/ longo prazo; 55

• blueprint; • pensar na estratégia do produto.

Você pode perceber que os papéis são bem parecidos, mas claro que temos uma diferença nítida em que o PM é focado 100% no negócio e o UX é focado 100% no cliente, ou ao menos deveria. Mas a interligação entre ambos é vista, de uma maneira mais clara, nas imagens abaixo:

A tri force de um PM

56

A tri force de um UX:

Esta dinâmica de trabalho fez com que o UX Design começasse a pensar muito mais nos objetivos do negócio (como na imagem acima), do que somente em entregar apenas a melhor experiência.

O UX Designer precisa sair do mundo de Alice e entender e coompreender o que está entregando, além de querer entregar apenas uma interface ou microinteração bonita. O produto final tem que atingir tanto as expectativas do cliente quanto da empresa que está atuando.

Portanto, o grande “trick” que faz o UX Designer evoluir em sua carreira é pensar e colocar em sua entrega a estratégia do produto, um product book que se adeque e tenha valor para o cliente final e seus stakeholders.

57

OK, mas ainda não entendi o que tem a ver UX designer em ser o próximo Product Manager?

TUDO! Conforme a sua evolução, o UX Designer amadurece seu lado estratégico e busca cada vez mais um lugar de relevância na empresa. Assim vemos a migração deste perfil para produtos e atingir uma influência no nível organizacional tão forte, que é capaz de ser a voz determinante da estratégia final da entrega do produto ou de uma feature.

Indiscutivelmente agora, mais do que nunca, o UX Designer está em um relacionamento mais maduro com as equipes de produto e encontra mais equilíbrio entre o que é retorno (de fato) para a empresa e uma boa experiência para o usuário.

Entendo e acredito que este equilíbrio, entre as necessidades de negócio e do usuário, pode ser feito por um bom Product Manager e quem pode assumir este cargo é o UX Designer. Lógico que tudo depende do que deseja de carreira, mas é um caminho mais que natural por estarmos em uma nova onda de transformação de skills e por ser um bom momento de provar seu valor em um nível de negócios. Uma vez que a maturidade de falar de igual para igual, como líder de produto, é mais que nítido.

Acredite, você é capaz sim! ;)

58

7 livros que toda pessoa de produto deveria ler Estes são os livros que considero essenciais para qualquer profissional que deseja entrar — ou acelerar seu desenvolvimento — no universo de produtos digitais.

Muita gente que deseja entrar no mercado de trabalho ou se desenvolver como Product Manager me faz algumas perguntas do tipo: • Como entender melhor o universo de produto e as competências necessárias para se tornar um PM? • O que separa um bom PM de um PM ruim ou apenas médio?

• Por onde começo? Faço um curso? Qual?

A disciplina (se é que podemos chamar de disciplina no sentido mais puro do conceito) de Gestão de Produtos Digitais é super inclusiva, isto é, aceita pessoas de diferentes áreas, formações e experiências profissionais — o que é bom e perigoso ao mesmo tempo. A gestão de produtos não é baseada em nenhuma escola formal (não existe faculdade de Product Management, como existem escolas de Design, Engenharia ou Ciências da Computação). Por isso não existe uma “ementa” básica do que estudar pra ser um bom profissional.

Paulo R. Floriano Chief Product Officer at Revelo — revolutionizing how people get hired and how companies recruit in Brazil.

59

Além disso a Gestão de Produtos é essencialmente técnica — teoria não adianta absolutamente nada se você não aplicar na prática e entender as variantes dos modelos e entender o que dá certo e errado em cada contexto. É só aí que você vai conseguir formar massa crítica para se tornar um(a) bom(a) PM. Existem cursos bons no Brasil (eu recomendo fortemente a Tera).

Mas minha recomendação é que, mesmo que você entre em algum curso ou bootcamp, leia os livros dessa biblioteca listada aqui. Dado que a maioria dos cursos são baseados nos processos e frameworks que esses livros apresentam, fica muito mais fácil assimilar se você entende o contexto/racional por trás de cada coisa.

Nesta lista, que não tem a intenção de ser completa ou extensa, coloco alguns livros que me ajudaram muito nos desafios do dia-a-dia em produto. Desde entender como validar uma hipótese de produto/ feature até como conversar com designers e desenvolvedores — passando por como usar dados pra tomar decisões mais informadas e definir melhores estratégias.

Product Management in Practice, de Matt Lemay.

Por que está na lista: primeiro de tudo, pra entender o papel de um PM eu prefiro este livro do que o Inspired (que vem logo a seguir na lista). Ele desconstrói aquela visão tradicional de que o PM está entre Tech, Business e Produto, que eu também não concordo em nada. Ao invés disso, ele propõe um modelo de “connective skills” (ou habilidades de conexão, numa tradução livre). Elas são: habilidade de comunicação entre dores de usuários e clientes com objetivos de negócio e dos stakeholders; organização dos times pra 60

alavancar colaboração, pesquisa de ideias e tendências e habilidade para executar a estratégia.

Inspired, de Marty Cagan (SVPG) Por que está na lista: recomendado por 95% dos PMs, é seguro dizer que é o guia definitivo (até agora) sobre Gestão de Produtos Digitais.

Escrito por Marty Cagan, uma das figuras mais representativas da área no mundo; foi do time que construiu Netscape e Ebay, na época que ainda se usava floppy disc. O livro se propõe a apresentar um framework para a gestão “moderna” de produtos digitais, no qual times são totalmente autônomos e produto/design/tech colaboram para descobrir oportunidades, validá-las com dados reais de mercado e construir apenas o que precisa ser construído — o que hoje chamamos amplamente de Product Discovery. Cagan é contra roadmaps tradicionais (o que eu também sou) e propõe uma alternativa, com o objetivo de construir o necessário para mitigar os principais riscos de um produto — que ele divide entre risco de valor, usabilidade, factibilidade/execução e viabilidade de negócio. Essa abordagem faz muito sentido pra mim e costumo usá-la no meu diaa-dia, por entrega mais valor do que a abordagem mais tradicional (outputs vs. outcomes).

Startup: Manual do Empreendedor: de Steve Blank e Bob Dorf Por que está na lista: foi meu livro de cabeceira durante alguns anos e o primeiro livro que eu costumo recomendar pra quem trabalha comigo. Pra mim é a melhor compilação de conceitos e métodos 61

sobre Lean Product Development (ou Lean Customer Delevopment).

Se você já leu A Startup Enxuta, esqueça tudo o que aprendeu e começe a ler esse livro com a cabeça aberta. Tudo o que você precisa saber sobre MVPs, experimentos, definição de hipóteses, mensuração e canais de distribuição está aqui. Vale, contudo, preparação prévia, pois ele é um livro denso e muitas vezes difícil de ler — mas vai fazer a diferença no seu trabalho.

High Output Management, de Andrew Grove Por que está na lista: todos os conceitos básicos sobre negócios modernos que você precisa saber, estão neste pequeno livro, lançado lá em 1983. Escrito por Andrew Grove, ex-CEO da Intel, ele apresenta conceitos básicos e super interessantes sobre gestão de empresas modernas (totalmente aplicáveis para a nossa realidade de produtos): métricas de entrada e métricas de saída, a importância de entender as de negócio como forma de atingir resultados de maneira mais eficaz, além do conceito de métrica de tração e métrica de qualidade — e como as duas são importantes pra se entender o todo.

Além disso, o livro é um dos precursores ao falar de modelos híbridos de organização — no qual a gestão por missão é tão importante quanto a gestão por função.

Radical Focus, de Cristina Wodtke Por que está na lista: é o livro mais divertido sobre OKRs que você vai ler. A primeira metade do livro mostra uma história fictícia, de Hanna e Jack, que vão perdendo foco ao longo do planejamento de um novo produto e isso os leva a tomarem decisões muito ruins para 62

seu projeto. A segunda metade do livro apresenta a metodologia de OKRs (Objectives and Key Results) de maneira bem didática.

Crossing the Chasm, de Geoffrey A. Moore Por que está na lista: poderia citar o fato de ter vendido um milhão de cópias, mas se esse fosse meu critério de escolha, entraríamos numa seara perigosa. Por isso, minha recomendação está no fato de que se você quer entender como funciona o ciclo de vida de um produto de tecnologia (e você precisa saber disso, vai por mim), você tem que ler este livro. Ele apresenta em detalhe como é o processo de adoção de um produto em suas diferentes fases por diferentes públicos: innovators, os famosos early adopters (tão mal interpretados nos dias de hoje), early majority, late majority e laggards.

E apresenta duas “rachaduras” no processo: quando o valor de um novo produto não consegue ser transmitido para uma parcela significativa do mercado (early majority). A segunda rachadura é na transformação de um produto que já é mainstream para um público ainda mais amplo (late majority), normalmente menos fiel e muitas vezes desproporcionalmente exigente.

Lean Analytics, de Alistair Croll e Benjamin Yoskovitz Por que está na lista: é até hoje meu livro de referência sobre métricas para produtos digitais. Além de conceitualmente interessante, ele traz propostas de como mensurar o sucesso de produtos por setor de atuação. Cada tipo de produto tem uma proposta de deck de métricas, com uma discussão bem profunda sobre sua utilização e pontos de atenção. Além disso, o Alistair Croll é um dos meus autores 63

favoritos sobre inovação em modelos de negócio. O blog dele, Tilt the Windmill, tem alguns dos textos mais legais que já li na interweb.

Menções honrosas para: • Predictable Revenue, pra entender sobre máquina de vendas B2B • Hooked, para entender como criar produtos que formem e mudem comportamentos • Lean Customer Development, para entender como startups e empresas grandes podem testar novas ideias com pouco ou nenhum código • Validating Product Ideas, idem • Universal Principles of Design, para entender conceitos básicos de Design e conseguir ter uma conversa mais alinhada com designers e pessoas de UX • Running Lean, para entender como planejar um processo que permita iterar modelos de negócio de maneira flexível • Escaping the Build Trap, para aprofundar conhecimentos sobre Product Discovery

Além disso, recomendo qualquer coisa que você puder ler ou assistir sobre desconstrução de estereótipos e valores tradicionais. Num mercado cada vez mais inclusivo (porém ainda longe, bem longe do ideal), um(a) PM precisa entender e acolher diferenças da melhor maneira, sejam elas quais forem. Isso já não é opcional, para qualquer profissional de produto.

64

O que aprendi nos meus primeiros 5 meses de product-led growth

Janeiro de 2020. Mês que eu entrei no novo time tech responsável pela aquisição de lojistas. Com o desafio, eu passei a devorar tudo do assunto: li muito sobre Growth Hacking, aprendi sobre The Bullseye Framework, descobri quem era Wes Bush (e agora sigo tudo o que ele faz).

Porém, nada substitui o famoso aprender fazendo. Vem que eu vou contar o que eu aprendi na prática e quais foram os nossos primeiros desafios com o modelo de aquisição product-led growth.

Mudanças são difíceis.

Processos demandam tempo. É preciso iterar, apertar os parafusos quase que diariamente para criar sinergia entre as pessoas e as ferramentas. Quanto maior o time, maior a complexidade. Então quando finalmente você, como líder, encontra um processo que faz sentido vem um time novo no pedaço falando que vão testar um tal de self-service! Quê?!

Andressa Siegel product designer at olist 65

Para evitar surpresas, o primeiro passo do nosso time foi alinhar com todas as pessoas diretamente impactadas sobre porquê, como e o que pretendíamos atingir com o novo modelo de aquisição.

Ouvir diferentes pontos de vista foi fundamental para descobrirmos os receios e o que nós poderíamos fazer para diminuir os riscos. Os constantes alinhamentos foram essenciais para que os stakeholders comprassem a ideia.

Hoje o nosso modelo híbrido de aquisição, onde vendedores “pescam” os leads durante o self-signup tem sido muito vantajoso para o olist como um todo, e só foi possível graças a todas as trocas de ideias.

Abre a porteira!

O objetivo do nosso time é growth, mas com responsabilidade.

Os problemas escalam junto com o aumento dos clientes (falei sobre o assunto em “A usabilidade arroz com feijão como essência do product-led growth ”), por isso nós temos reuniões semanais com os times de produto para que as ações sejam sincronizadas, garantindo o crescimento da empresa com segurança.

Somos um só time.

No passado do olist era muito claro onde terminava a responsabilidade de Marketing e onde começava a de Produto. Isso era ruim tanto para nós, olisters, quanto para os clientes. Desde o início de 2020, nosso time tem se aproximado de Vendas e Marketing, 66

trabalhando juntos com o mesmo propósito. Um dos meios para promover essa interação tem sido os checkpoints semanais com: • SDRs (pré-vendedores), onde eles trazem highlights das dores dos leads, quais as personas que têm fechado os planos, quais as possíveis oportunidades e sugestões sobre como nós, time de Produto, podemos ajudar com os seus processos internos; • Marketing, onde conversamos sobre as taxas de conversão, quais os resultados dos últimos experimentos e quais ações parecem importantes para próximos passos.

Desapega!

Felizmente aprendi cedo na minha carreira como designer a ter desapego. Isso não significa entregar algo mal planejado, mas sim ter consciência de que lapidar por meses uma interface não é o melhor caminho para o crescimento exponencial.

Por isso, faça o melhor que você pode com os dados que você tem, implemente e acompanhe os resultados. Se funcionar, continue iterando. Caso contrário, descarte a ideia e vá para a próxima. Aposte e aprenda rapidamente.

Comemore cada conquista.

A meta é agressiva, mas é importante sempre comemorar os ganhos com o time :) Cada aumento nas porcentagens é um motivo! Eu brinco com o time que em cada subida e descida nos gráficos eu escuto o Galvão berrando na minha mente a narração do vai ganhar, vai perder, perdeu… ganhou!

67

Para mim tem sido divertido trabalhar com pessoas de diferentes especialidades, testar rápido novas hipóteses, acompanhar os dados e a cada semana ter novos aprendizado.

Espero que vocês tenham curtido. Compartilhem o artigo e comentem quais outros desafios vocês têm encontrado com product-led growth.

68

1ª edição impressão papel de miolo papel de capa tipografia

JUNHO DE 2020 BARTIRA PÓLEN SOFT 70G/M² CARTÃO SUPREMO 250G/M² HELVETICA NOW