Vi digger å jobbe tett med produkteiere! Det er essensielt for å få produktteamet til å fungere godt. Produkteier er ofte en supergod støttespiller for det brukersentrerte perspektivet. Men noen ganger fungerer samarbeidet mellom UX-designeren og produkteieren ikke like godt. Hva påvirker dette samarbeidet? Når blir det bra og når blir det krise? Her er noen refleksjoner etter en diskusjon mellom flere UX-designere i Bekk.

Gå for kontinuerlig kommunikasjon!

En helsesjekk for kommunikasjonen i teamet er å vurdere hvor ofte dere snakker sammen. Et tegn på usunn kommunikasjon er at én av teammedlemmene har flere møter med andre enn med teamet. Rollene i et team er naturligvis i ulike møter, og da må vi ha som mål å kontinuerlig kommunisere til hverandre det en har hørt i de ulike møtene. Slik kan en skape en god felles oversikt og det styrker teamets evne til å ta gode valg.

En konsekvens av å ikke ha kontinuerlig dialog er at viktig informasjon ikke deles til riktig tid. Produkteier får gjerne forespørsler og informasjon fra mange forskjellige kilder. Dersom produkteier ikke får informasjon, oversikt og forståelse for hva som bør gjøres fra fagpersonene i teamet, står de med et begrenset beslutningsgrunnlag når de sier ja til å “slippe inn” oppgaver i backlogen. Vi har i flere situasjoner opplevd konflikter som kunne vært unngått ved å dele mer informasjon tidligere.

For eksempel kan utviklerne komme frem til at det er nødvendig å gjennomføre omfattende tekniske forbedringer. Dersom produkteier ikke forstår hva som bør gjøres, hvorfor det bør gjøres og når det bør gjøres, kan dette resultere i at produkteier har et helt annet syn på hva som bør prioriteres.

Eller at designer ikke deler innsikt løpende eller ikke tar med teamet på innsiktsarbeid. Da kan produkteier argumentere for å prioritere inn oppgaver basert på innspill og bestillinger fra andre aktører, mens designeren mener det ikke vil treffe brukerens behov. Har en først prioritert noe, så er det verre å ta det tilbake. Det beste er om en ikke kommer i situasjonen der en av rollene har prioritert opp noe for hele teamet, uten at hele teamet er involvert.

Vår erfaring er at tett dialog i stor grad styrker oss som utviklingsteam! Med tett dialog mener vi at teamet snakker sammen hver dag, gjerne flere ganger daglig.

Hvilke rutiner har dere for tett og kontinuerlig dialog? God standup for daglig kommunikasjon? Ukentlig prioriteringsmøte? Kanskje det kan hjelpe å ta en gjennomgang av hvilke møtepunkter teamet har?

Del informasjon løpende og kommuniser med teamet daglig.



Å snakke med (og ikke om) den du irriterer deg over 😬🤭🫣

Kommunikasjon er vanskelig! Det kan oppstå uenigheter mellom f.eks. produkteier og designer. Uenigheter kan være bra for å skape de beste løsningene. Det er jo en grunn til at vi jobber tverrfaglig — vi skal ta med ulik bagasje og synspunkter inn i produktutviklingen. Vær åpen og ærlig rundt synspunktene dine, og ta tid til å diskutere det som skurrer. Vis og forklar resonnementet, og ikke bare kom med konklusjonen. Unngå “paradise hotel”-kommunikasjon. Med dette mener vi: unngå å ta opp problemstillinger med alle andre enn med de som faktisk er uenig med deg. Vi har alle erfaring med at vi etter et møte har vært frustrert og gått til våre “allierte” (f.eks. en i teamet, en venn, personalansvarlig) for å lufte frustrasjonen. Det kan være godt å lette på trykket, men vær bevisst på at det ikke er produktivt i den faktiske diskusjonen, med mindre du får tips til hvordan du bør ta tak i problemstillingen videre.


Hvem går du til når du ønsker å lufte utfordringer i hverdagen? Noe som kan hjelpe er å prøve å forstå hvorfor dere egentlig er uenige, og så ta det opp med den det gjelder.

Unngå “paradise hotel”-kommunikasjon!

Hverdagen i et team fungerer dårlig når vi tenker at jobben vår er begrenset til “rollen” vår

Vi må slutte å snakke om arbeidsoppgaver knyttet til rolle. Vi må snakke om hvilke arbeidsoppgaver teamet har. Hva skal til for å lage et knallbra produkt? Det er, selvfølgelig, så mye mer enn de klassiske arbeidsoppgavene som “tegne en skisse”, “være i et møte” eller “skrive en kodelinje”. For eksempel hvis en produkteier som jobber i et team kun er opptatt av å måle effekten av produktet, men ikke ønsker å jobbe sammen med teamet på alt som skal til for å få til et godt produkt, så vil samarbeidet skurre.

Vi har ulike roller inn i et tverrfaglig team for å ha med ulik kompetanse og perspektiver, men det er et must at vi faktisk samarbeider i teamet. Hva betyr det i praksis? Det betyr at vi ofte må gjøre arbeidsoppgaver som ikke nødvendigvis er én rolle sitt typiske ansvar. At en produkteier kan ta ansvar for rekruttering av brukere til intervju. At en designer kan ta ansvar for personverndokumentasjon. At en produkteier argumenterer for å bruke tid på teknisk gjeld. At en utvikler kan ta hovedansvaret for å ta notater fra et brukerintervju. Det er ikke nødvendigvis en klassisk arbeidsoppgave for rollen — men det er en del av det å være med i et team som lager et digitalt produkt.



Teamet må forstå hvor hver enkelt kommer fra og hva arbeidsoppgavene til hele teamet er. Opplever du at folkene i teamet ditt har for mye fokus på sin egen rolle? Det finnes ikke noe enkel medisin, men her er noe som kan testes ut:

Være mer bevisst antagelsene vi har om hverandre: Snakk om forventninger til hverandre. Hvilken bakgrunn har du? Hvilket fag “kommer du” fra? Hva er din erfaring med å lage digitale produkter?

Hvem tar beslutninger? Hvilke beslutninger tar designer og hvilke tar produkteier?

Snakk om forventninger til hver enkelt: Hva opplever du at du blir målt på? Hvem har forventninger til deg utenfor teamet? Hva gjør du på jobben når du tenker “dette er en bra arbeidsdag”?

Test ut Team Canvas og spesielt delen om roller. En morsom variant er å ikke beskrive sin egen rolle og bidrag inn i teamet, men at de andre skal beskrive din rolle. Prøv å la folk lufte noen antagelser om hverandres bidrag inn i teamet.

Hverdagen i et team fungerer best når vi tenker at jobben vår er alle de arbeidsoppgavene teamet har. At vi jobber SAMMEN.


Samarbeidet fungerer dårlig når man har blikket på to helt forskjellige horisonter

Som designer liker vi ofte å ha overblikk og vite hvor vi skal, vi har gjerne blikket på horisonten. Hvordan får vi det overblikket? Har produkteieren overblikk? Og ser vi det samme? 👀 Vi synes det fungerer best når hele teamet har tett dialog om veien vi skal gå sammen — hvorfor vi prioriterer som vi gjør, hvor vi skal på kort og lang sikt, og med hvilken fart vi reiser. Men hvordan får man til dette? 🤔 Har vi gode nok rutiner for å ikke bare se det som skjer rett foran oss, men også innimellom stoppe opp og se hva som skjer på lengre sikt? Når vi er veldig flinke på å levere funksjonalitet kontinuerlig og raskt, hva skjer da om vi glemmer å se fremover? Det er veldig tilfredsstillende å ta ett og ett steg, men noen ganger må man stoppe opp, se framover og se om vi går i riktig retning.

Hva er målet til teamet? Hvordan kom vi frem til det? Sannsynligvis har samtlige i teamet mål om å lage så gode tjenester som mulig. Vi må huske på dette når vi kommuniserer. Det kan være svært nyttig for hele teamet å sette av god tid til å formulere et klart og tydelig felles mål — det er aldri for sent å gjøre dette. Med et tydelig mål kan vi la diskusjonene handle om hvordan vi sammen skal kunne nå dette målet. Er vi uenig om detaljer, men vet at vi forsøker å nå det samme målet, kan dette sette en helt annen tone i diskusjonene.

Det er mange måter å jobbe mot et felles mål; mange har de siste årene tatt i bruk OKRer, Noen av oss har hatt suksess med Product Discovery og Opportunity Solution Tree. Det viktigste er å finne noe som passer for ditt team — slik at alle har et felles bilde av:

Dagens status — hvor er vi nå

Hvor skal vi? Målet vårt på kort og lang sikt

Kapasiteten til teamet

Hvilken fart har vi? Skal alle ha samme fart?

Designer og produkteier må jobbe tett og skape forståelse for et felles mål.

Så må vi jo runde av med at vi som UX-designere setter svært stor pris på å jobbe tett med produkteiere! Vi trenger dette samarbeidet for å produsere et skikkelig bra produkt, og å ha en god prosess på veien. Dette var noe av det vi diskuterte i gruppa, vi håper det satt i gang noen tanker hos deg. Del det gjerne — det trenges flere hoder med i diskusjonen rundt hvordan produkteier og designer best samarbeider for å skape råbra tjenester!

Lesetips:

📕 Inspired av Marty Cagan

📗 Continuous Discovery Habits av Teresa Torres

📘 Radical Focus 2.0 av Christina Wodtke

💻 How product managers lose trust — John Cutler

PS: Er ikke egentlig selve ordet produkteier et krevende ord — setter det for mye føringer på hvem som eier produktet? Hva skjer om vi i stedet setter fokus på at det er teamet — sammen — som eier produktet? Men det er en helt annen bloggpost… 😅


Basert på diskusjon i en faggruppe med flere UX-designere i Bekk

Designer, produkteier, teamet…. Hvordan samarbeider vi?

How are different teams facilitating their Monday and Friday meetings? I have sought inspiration for my own team by talking to colleagues working in different teams and organizations. I hope this can also inspire some of you!

If you work in a digital product team in 2022 you may have heard of the OKR framework. With OKRs often comes "Monday Commitments" and "Friday Wins". Meetings that are meant to set goals for the week on Monday, and celebrate your achievements on Friday.

As teams and organizations can be organized in different ways, I’ve been curious about all the different ways these meetings are facilitated. So I talked to a couple of colleagues to find out how they have made them work out for their team. Why do they have them? What works and what doesn't? Maybe these experiences can spark some ideas as to how you can adapt these methods to your own unique team.


Lars Andreas and Markus from Spink

Our Product Owner works remotely, so we do our Monday and Friday meetings digitally. It is a truly important gathering point for our team. Our Monday Commitment meeting agenda is written as a Trello task, readily available and right next to our backlog. Though sometimes, we’ll admit, we forget to look at it. Every week we rotate on having the responsibility to make sure we are working towards those commitments. 


The way we write our commitments is more “big picture”, not concrete tasks. For example: Our goal is to get this in production – not all the steps it takes to get there.

Making commitments for the week does, to a certain extent, help us keep focused and prioritize what we should do throughout the week. Although by the end of the week we often haven’t done all the tasks we committed to, mostly due to unexpected new tasks that are more urgent.

Though we usually don’t get to everything we would like to, we like doing the Monday Commitments because of two things:

It really sets a focus for the week. “This is what we are focusing on – and this other thing we will put aside this week.”

We check our commitments each week to see what we should work on next. It is a good to-do-list (better than our backlog), because it is always up to date.



Markus from Möller Digital

Our team rituals consist of Monday Commitments, daily standups, and Friday Wins.

For our Monday Commitment meetings we close our Jira board completely, and enter a little corner in our Miro board instead. Here we set common goals for the team to accomplish this week, without tagging specific people to a task. Some of the goals are "low hanging fruits" – others more of a stretch goal. These meetings work well to frame our Jira-tasks. The Jira-tasks are often so specific that it’s hard to see the bigger picture. As a designer, I get more invested in what we are making than I would have been if I was just focused on the concrete Jira-tasks. In the long run, we should get better at linking our commitments to our OKRs.  We do have a way to go there. The OKRs at Möller have up until recently only been on a higher level in the organization. A few weeks back we sat down with the team and made OKRs on a team-level. So in the weeks to come we will hopefully get better at linking our commitments with our teams  OKRs.

For Friday Wins, we put up our Miro board and look at what we have accomplished, color code it, and celebrate that. If there is something we haven't done, we bring it with us for the next week.



Citona from SpareBank 1

Right now we are in a phase where we are trying to figure out what works for us and what doesn’t. We are a big team and have recently divided ourselves into three sub-teams with three different focus areas. We are responsible for a lot of different functionality, so it is quite hard to set goals that everyone can gather around. The three sub-teams make it possible for everyone to have ownership and focus on a specific goal. Our hope is that the sub-teams manage to make goals that contribute towards the “main goal”, so that they become visible to everyone.

We previously used the OKR system with Monday Commitments and Friday Wins. Most teams in our organizations were doing it, and we initially wanted to take part in this thing that seemed to be working so well for everyone. For our team, though, using the methodology felt a bit forced. However, I do not believe there's anything wrong with the framework itself. We are just not quite rigged for OKRs as we have a wide variety of functionality, a lot of maintenance, and legislations that have to be taken into account. So we stopped, took a step back and asked ourselves: What does our team need to find focus and make progress? What we need is a simple meeting on Mondays where we gather and talk about what we are going to do this week.

Although we dropped the classical Friday Wins format as well, we do believe it is important to celebrate our achievements. Every Friday became a bit too often though, as we didn't necessarily achieve that much within a week. Also, after Covid a lot of people continued to work remotely on Fridays, and frankly celebrating in a hybrid meeting or on zoom just isn’t the same.

So this is what we are doing right now: Every ⁠M⁠onday ⁠the whole team get together in the office. One representative from each sub-team shares something that they are proud of from the previous week, and then what the sub-team plan on doing this week. So in a way we have combined some celebration and some planning in the same meeting. We also try to celebrate along the way. We do that by continuously following numbers and measurements, and when we have bigger launches we of course have cake!

So.. Was the fuss worth fussing about?

To have a clear focus and be able to acknowledge and celebrate your achievements, big or small, is undeniably important for personal motivation and for your team to succeed. Monday Commitments and Friday Wins are nice ways to really put it on the agenda. Though, it is important to remember why you do it, and keep reflecting with your team on what works. Do the tweaks needed for your unique team to feel ownership and motivation! I hope reading about my colleagues experiences could inspire you to do just that.

Monday Commitments and Friday Wins. What’s the fuss?

Hva skal til for å få et godt samarbeid mellom produkteier og designer? Og et godt samarbeid i teamet? 

Samarbeidet fungerer dårlig når man har blikket på to helt forskjellige horisonter

Som designer liker vi ofte å ha overblikk og vite hvor vi skal, vi har gjerne blikket på horisonten. Hvordan får vi det overblikket? Har produkteieren overblikk? Og ser vi det samme? 👀 

Vi synes det fungerer best når hele teamet har tett dialog om veien vi skal gå sammen — hvorfor vi prioriterer som vi gjør, hvor vi skal på kort og lang sikt, og med hvilken fart vi reiser. Men hvordan får man til dette? 🤔 Har vi gode nok rutiner for å ikke bare se det som skjer rett foran oss, men også innimellom stoppe opp og se hva som skjer på lengre sikt? Når vi er veldig flinke på å levere funksjonalitet kontinuerlig og raskt, hva skjer da om vi glemmer å se fremover? Det er veldig tilfredsstillende å ta ett og ett steg, men noen ganger må man stoppe opp, se framover og se om vi går i riktig retning.

Hva er målet til teamet? Hvordan kom vi frem til det? Sannsynligvis har samtlige i teamet mål om å lage så gode tjenester som mulig. Vi må huske på dette når vi kommuniserer. Det kan være svært nyttig for hele teamet å sette av god tid til å formulere et klart og tydelig felles mål — det er aldri for sent å gjøre dette. Med et tydelig mål kan vi la diskusjonene handle om hvordan vi sammen skal kunne nå dette målet. Er vi uenig om detaljer, men vet at vi forsøker å nå det samme målet, kan dette sette en helt annen tone i diskusjonene.

Det er mange måter å jobbe mot et felles mål; mange har de siste årene tatt i bruk OKRer, Noen av oss har hatt suksess med Product Discovery og Opportunity Solution Tree. Det viktigste er å finne noe som passer for ditt team — slik at alle har et felles bilde av:

Dagens status — hvor er vi nå

Hvor skal vi? Målet vårt på kort og lang sikt

Kapasiteten til teamet

Hvilken fart har vi? Skal alle ha samme fart?

Vårt tips: Designer og produkteier må jobbe tett og skape forståelse for et felles mål.


Lesetips

💻 How product managers lose trust — John Cutler



Hvordan samarbeider vi? Del 4



Hverdagen i et team fungerer dårlig når vi tenker at jobben vår er begrenset til “rollen” vår 

Vi må slutte å snakke om arbeidsoppgaver knyttet til en rolle. Vi må snakke om hvilke arbeidsoppgaver teamet har. Hva skal til for å lage et knallbra produkt? 

Det er, selvfølgelig, så mye mer enn de klassiske arbeidsoppgavene som “tegne en skisse”, “være i et møte” eller “skrive en kodelinje”. For eksempel hvis en produkteier som jobber i et team kun er opptatt av å måle effekten av produktet, men ikke ønsker å jobbe sammen med teamet på alt som skal til for å få til et godt produkt, så vil samarbeidet skurre.

Vi har ulike roller inn i et tverrfaglig team for å ha med ulik kompetanse og perspektiver, men det er et must at vi faktisk samarbeider i teamet. Hva betyr det i praksis? Det betyr at vi ofte må gjøre arbeidsoppgaver som ikke nødvendigvis er én rolle sitt typiske ansvar. 

At en produkteier kan ta ansvar for rekruttering av brukere til intervju. At en designer kan ta ansvar for personverndokumentasjon. At en produkteier argumenterer for å bruke tid på teknisk gjeld. At en utvikler kan ta hovedansvaret for å ta notater fra et brukerintervju. 

Det er ikke nødvendigvis en klassisk arbeidsoppgave for rollen — men det er en del av det å være med i et team som lager et digitalt produkt. Teamet må forstå hvor hver enkelt kommer fra og hva arbeidsoppgavene til hele teamet er. 

Opplever du at folkene i teamet ditt har for mye fokus på sin egen rolle? Det finnes ikke noe enkel medisin, men her er noe som kan testes ut:

Være mer bevisst antagelsene vi har om hverandre: Snakk om forventninger til hverandre. Hvilken bakgrunn har du? Hvilket fag “kommer du” fra? Hva er din erfaring med å lage digitale produkter?



Hvem tar beslutninger? Hvilke beslutninger tar designer og hvilke tar produkteier?



Snakk om forventninger til hver enkelt: Hva opplever du at du blir målt på? Hvem har forventninger til deg utenfor teamet? Hva gjør du på jobben når du tenker “dette er en bra arbeidsdag”?



Test ut Team Canvas og spesielt delen om roller. En morsom variant er å ikke beskrive sin egen rolle og bidrag inn i teamet, men at de andre skal beskrive din rolle. Prøv å la folk lufte noen antagelser om hverandres bidrag inn i teamet.

Vårt tips: Hverdagen i et team fungerer best når vi tenker at jobben vår er alle de arbeidsoppgavene teamet har. At vi jobber SAMMEN.

Hvordan samarbeider vi? Del 3



Å snakke med (og ikke om) den du irriterer deg over 😬🤭🫣

Kommunikasjon er vanskelig! Det kan oppstå uenigheter mellom f.eks. produkteier og designer. Uenigheter kan være bra for å skape de beste løsningene. 

Det er jo en grunn til at vi jobber tverrfaglig — vi skal ta med ulik bagasje og synspunkter inn i produktutviklingen. Vær åpen og ærlig rundt synspunktene dine, og ta tid til å diskutere det som skurrer. Vis og forklar resonnementet, og ikke bare kom med konklusjonen. 

Unngå “paradise hotel”-kommunikasjon. Med dette mener vi: unngå å ta opp problemstillinger med alle andre enn med de som faktisk er uenig med deg. Vi har alle erfaring med at vi etter et møte har vært frustrert og gått til våre “allierte” (f.eks. en i teamet, en venn, personalansvarlig) for å lufte frustrasjonen. Det kan være godt å lette på trykket, men vær bevisst på at det ikke er produktivt i den faktiske diskusjonen, med mindre du får tips til hvordan du bør ta tak i problemstillingen videre.

Hvem går du til når du ønsker å lufte utfordringer i hverdagen? 



Noe som kan hjelpe er å prøve å forstå hvorfor dere egentlig er uenige, og så ta det opp med den det gjelder.

Vårt tips: Unngå “paradise hotel”-kommunikasjon! 

Hvordan samarbeider vi? Del 2



Gå for kontinuerlig kommunikasjon!

En helsesjekk for kommunikasjonen i teamet er å vurdere hvor ofte dere snakker sammen. Et tegn på usunn kommunikasjon er at én av teammedlemmene har flere møter med andre enn med teamet. 

Rollene i et team er naturligvis i ulike møter, og da må vi ha som mål å kontinuerlig kommunisere til hverandre det en har hørt i de ulike møtene. Slik kan en skape en god felles oversikt og det styrker teamets evne til å ta gode valg.

En konsekvens av å ikke ha kontinuerlig dialog er at viktig informasjon ikke deles til riktig tid. Produkteier får gjerne forespørsler og informasjon fra mange forskjellige kilder. Dersom produkteier ikke får informasjon, oversikt og forståelse for hva som bør gjøres fra fagpersonene i teamet, står de med et begrenset beslutningsgrunnlag når de sier ja til å “slippe inn” oppgaver i backlogen. Vi har i flere situasjoner opplevd konflikter som kunne vært unngått ved å dele mer informasjon tidligere.

For eksempel kan utviklerne komme frem til at det er nødvendig å gjennomføre omfattende tekniske forbedringer. Dersom produkteier ikke forstår hva som bør gjøres, hvorfor det bør gjøres og når det bør gjøres, kan dette resultere i at produkteier har et helt annet syn på hva som bør prioriteres.

Eller at designer ikke deler innsikt løpende eller ikke tar med teamet på innsiktsarbeid. Da kan produkteier argumentere for å prioritere inn oppgaver basert på innspill og bestillinger fra andre aktører, mens designeren mener det ikke vil treffe brukerens behov. Har en først prioritert noe, så er det verre å ta det tilbake. 

Det beste er om en ikke kommer i situasjonen der en av rollene har prioritert opp noe for hele teamet, uten at hele teamet er involvert.

Vår erfaring er at tett dialog i stor grad styrker oss som utviklingsteam! Med tett dialog mener vi at teamet snakker sammen hver dag, gjerne flere ganger daglig.

Hvilke rutiner har dere for tett og kontinuerlig dialog?



God standup for daglig kommunikasjon? Ukentlig prioriteringsmøte?



Kanskje det kan hjelpe å ta en gjennomgang av hvilke møtepunkter teamet har?

Vårt tips: Del informasjon løpende og kommuniser med teamet daglig.

Hvordan samarbeider vi? Del 1

To all UX-designers: Stop working alone, start pair designing and embrace collaboration. 

UX-designers may find it frustrating that others have opinions about their design. That it's tiring that anybody can say how the digital product should work.

But it's not your design! As a UX-designer you´re part of a team. What the users experience out there in the real world - that is the design. And so many people were a part of creating it! The whole product team decides what to make, and how it is made. That is what interdisciplinary collaboration really is.

Everybody can design

Everybody can have an opinion about how something should work. Which component from the design system we should use. Or if this or that button should be bigger. It doesn't mean that it will become a great design, but everyone is able to have opinions about it. Think about what these opinions really are. It´s commitment. People who really want the product to become the best product for the users. This is something we as UX-designers should cheer on!

When we UX-designers sit alone and sketch, we end up creating sketches that we hand over to others. While sketching we consider lots of different possibilities and end up making many small and big decisions in the process. We might think that these sketches are the design of the product, but what it really is is just a way of communicating what the team could develop. It´s 2022.  We can't continue with handovers in an agile team making digital solutions! If we simply hand over sketches, we are not collaborating. We are wasting time on misunderstandings between team members. If you get input and the discussion happens after you have landed on what you think is the best, that will not make a useful discussion! If you think we don't have time for the interdisciplinary discussions, that it will take too much time, I’m here to tell you that those discussions will come anyway but they will just come at a later stage. If we continue with handovers we remove the possibility of developing co-ownership for the product we make. An ownership to the whole product, and to all those big and small decisions on why it looks like it does, and works like it does.

Please stop working alone. Start pair designing!

Don't work alone with your sketches. I’m not saying this is easy. There will be more discussions and disagreements than if you sit with your design by yourself. Try to pair design with your team. Include the developers and the product manager. We might have to think a bit more about our arguments and explain why we think that a radio button rather than a dropdown-menu works best in this context. Or why we should make this rather than that. It might be a bit more stressful to dig deep to find the words to argue. But maybe this can lead to a better product over all?

The whole group that is pair designing has to argue and explain their opinions. No one can continue to throw out suggestions or opinions, but rather start to explain why they think one product decision is better than the other. Dear UX-designer, give your team the opportunity to be closer to the big and small product decisions. This gives everyone the opportunity to understand the complexity around the users and the domain that we need to have knowledge about to make the best product choices.

If you think that you can't start working like this in your team. If you will be too unpleasant. If it's too stressful to discuss with your closest collaborators... Then you have to do something about that challenge. Try a Team Canvas, build psychological safety, and so on.

Stop handing over sketches in your team. Involve the team, sketch together, and empower the team to see the users perspective and start pair designing. Don´t bother being right. There is no perfect way to design a user interface. Decide together how the product should work!

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

What did you feel while reading? Did it spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start a debate! Remember that the goal of Brannfakler is to start discussion!

Product development

Designer, produkteier, teamet…. Hvordan samarbeider vi?

Monday Commitments and Friday Wins. What’s the fuss?

Hvordan samarbeider vi? Del 4

Hvordan samarbeider vi? Del 3

Hvordan samarbeider vi? Del 2

Hvordan samarbeider vi? Del 1

Dear UX-designers, don't work alone!

Sign up for our newsletter

Join in the holiday cheer and count down to Christmas with us!