Heather Wydeven- Designers + Developers: So Happy Together (Evolution)
•Transferir como PPTX, PDF•
0 gostou•919 visualizações
If you've ever worked on a cross-functional team comprised of designers and developers, you know that integrating the two successfully can be challenging. Heather will share learnings from her own experiences about how designers and developers can flourish together and deliver great software. Attendees will walk away with an understanding of the following: 1) why cross-functional teams are necessary to build successful digital products; 2) the reasons cross-functional teams fail and the challenges between designers and developers; 3) the characteristics of a healthy cross-functional team; 4) how to create a successfully integrated team of designers and developers by fostering open communication, sharted understanding, respect, and trust building; and 5) a better understanding of and appreciation for the differences and strengths each role brings to a team.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (15)
Semelhante a Heather Wydeven- Designers + Developers: So Happy Together (Evolution)
Semelhante a Heather Wydeven- Designers + Developers: So Happy Together (Evolution) (20)
Mais de Thoughtworks
Mais de Thoughtworks (20)
Último
Último (20)
Heather Wydeven- Designers + Developers: So Happy Together (Evolution)
- 1. HEATHER WYDEVEN Experience Designer @heatherwyd #EvolutionTW #ThoughtWorks
- 2. designers + developers: so happy together HEATHER WYDEVEN © Nintendo
- 3. We are all responsible for creating experiences. © Marvel Artwork by Gigei
- 4. We’re all in this together. © Peanuts
- 5. Why cross-functional teams fail
- 6. individual mindset vs team mindset diva designers and disgruntled devs team members working in isolation© Marvel
- 7. Developers, on designers: You’re too precious about your work, and you dream too big. It’s not possible to achieve all of that! You only care about making things pretty. Designers, on developers: You think too much inside the box, and you tell me you can’t implement anything I’ve put so much work into designing! YOU THINK WHAT??! © DC Comics
- 8. Outcomes of a healthy cross-functional team
- 9. shared understanding developers can design too pragmatic problem solving Artwork by Mighty355
- 10. Creating a successful cross-functional team
- 11. 1 choose empathy © Peanuts Artwork by 822PeppermintPatty66
- 12. 2 leave your ego at the door © Disney
- 13. 3 embrace other perspectives © Gete Comunicación
- 14. 4 build trust Artwork by 93Cobra © Marvel
- 15. 5 take the journey together © Pokemon
Notas do Editor
- Today I want to tell you a story about my first time… working with a developer. The year was 2013, and I was a bright-eyed, brand new User Experience designer, staffed on my first project with a developer. Up to this point, the extent of my interaction with developers was limited to 30 min design handoff meetings, and communicating messages through my PM. One day my UX lead suggested I reach out to our developer and ask him for feedback on my designs. So I did, and it was the beginning of a great partnership. My developer happened to be working remotely, a few hours from me, so we communicated every day via Google Hangouts. We got to know one another, and soon we even chatted about more than our work, finding common ground in things like sports and music. As they often do, one day our stakeholder approached us with a last minute change. The website we were building had to be 508 compliant, which in the US means it needed to be accessible to people with physical impairments. This meant changing the entire visual design. I struggled to make some of the changes alone, and then began discussing with my developer, when he said to me: “You know, I’m color blind.” He and I spent an afternoon pairing together, trialing new colors in the design, he giving me immediate feedback, until we arrived on a solution that worked. The client approved, and he was able to implement the changes directly in the code. From then on, I was hooked. Hooked on working with developers. I began to see them as my ally, an essential part of my creative process. I needed them if I wanted to be truly successful and effective as a designer. I am very passionate about the topic of designer/developer collaboration, and today I want to share my experiences with you. I’ve seen the good, and the bad, teams that work well together, and teams that are dysfunctional. I want to help you understand the importance and value of this kind of collaboration, and how you can create cross-functional teams that work effectively and efficiently.
- Set the groundwork… we are all responsible for creating experiences I know experience is in my job title but… it’s up to all of us We’re superheroes who need each other to “save the world from bad experiences” We hired to solve problems and create experiences… but we need one another to do it! But like this team of superheroes, we each have different skillsets, strengths to compensate for someone else’s weaknesses This is what makes a cross-functional team
- no one person or role is more important than another we actually need each other to do this we are working toward the same goals, we want the same things
- Define a cross functional team
- teams get into trouble when individuals on the team make it all about them.. for example, when a team member is more concerned about his or her personal agenda than working towards the united cause of the team designers want it their way and don’t want to budge on the painstaking work they’ve created… and it’s more about the beauty of the design than the functionality or feasibility. developers are buried in tech debt, constraints can also have diva devs, who care about having such perfect code that they accumulate a lot of tech debt isolation: devs are afraid of designers
- These are stereotypes/biases, while not everyone thinks this, I want to call attention to some common misconceptions that each role has for the other… they are things I’ve heard, or even thought myself what I want you to know about designers… we aren’t all like that what I know about developers… you aren’t all like that:) older mindset, ways of working will speak about some approaches to dealing with these stereotypes
- less challenging of work from devs, know the why devs can design too… invite them into the process, share ownership/responsibility for creating the experience Share NFL experience, have seen how all these things work successfully on a cross-functional team I want to hear what’s in your head, you can inform my design work
- people focused, not logistical or process specific we are all humans who work with other humans, and learning how to see each other as people will help us achieve successful product outcomes and work together more cohesively
- it’s not just for users, it’s for each other, the ones we have to work with on a daily basis intentionally talking about it first, because it lays the groundwork for success, it disarms people Be curious, seek understanding, ask questions to clarify and identify the root of the behaviour Put yourself in the other person’s shoes acknowledge their struggle or situation, be patient when questions are asked, they aren’t in your mind get to know each other as people, so important.. be good to people learn how to approach one another, learn about one another’s styles
- we are creatively minded people, in tech it’s not about you. it’s about the team, not any one individual, we each have an equal part to play No small parts only small actors You can only control yourself, so model the behaviour you want to see.. Demonstrate you’ve left your ego behind by being open to other people’s ideas You value the outcome of the team more than the outcome of you as an individual …. you aren’t the most important one this is not easy… I had a situation recently with a developer, where I found myself listening to his feedback and getting a bit irritated. I asked myself, why am I so irritated right now, he’s just doing his job and raising concerns about implementation. I realised I was the issue. I thought I had designed an interaction that worked really slick, and I wanted to be the smart designer. But it’s not about that, and I had to check myself right then and there. The feedback I received was good, and his suggestion meant more ease for the user, and once I put my own ego aside, I was able to realise this and accept that it’s okay not to be right all the time, or the ideas that are chosen in the end. It’s about finding a solution that works, not about whose idea is right. not about being the best person, about being the best TEAM you can be.. Leave your ego at the door, and you’ll be easier, more approachable person to work with.
- this is what make teams so unique! what are the other perspectives? a designer has this perspective to offer… dev has this perspective to offer… embrace both sides perspective is meant to be shared Invite perspective, Leave your ego behind, ask with an open mind Communicate what’s important to you, ask the other what is important to them Find your common ground.. perhaps this can be the fact that we are all trying to solve the same problem, just coming at it from different angles and bringing our own perspectives Build in a habit of doing this for each iteration or feature design that happens don’t sacrifice valuable collaboration in favour of fast delivery timelines
- considering the thoughts and experiences of those on the team builds trust.. demonstrate you are considering the effort of others on your team when you design or develop if there's no trust, work is constantly questioned in the wrong ways and work can be redone or wasted all the things we’ve discussed designers, this is what I do… ask dev what will be helpful for the design.. how do they want assets delivered, screen size, responsive shows them I’m not going to go away and design in isolation and throw something over the fence developers, some tips for speaking with designers: - ask questions, if you don’t understand why a designer made a specific design decision, or you don’t understand how it’s meant to function - if a designer gets defensive, choose empathy, explain why you need to know and demonstrate that you care about knowing - explain why you do things, and the importance of what you do, and the impact of a designer’s work technically, if they don’t already know this - explain things in a non-tech way, in common language that non-tech people can understand
- start by getting to know each other! integrating early, throughout delivery.. integrate dev in design meetings, and design in dev meetings involve them in research and testing, devs ask to be involved if you aren’t already pair together from the start as features are in early day concepts… sketch with devs! don’t design in isolation… co-locate achieving shared understanding… developers have a better understanding of why you design something the way you did and may be less likely to challenge or able to offer a better solution that still helps users seniors & leads, model this behaviour for your younger/junior devs take an evolutionary, personal approach to the way you work together … we may have in our minds some rules and guidelines from older ways of doing things.. rewrite the rules for your team and what works for you give yourselves permission to incorporate with one another.. breakdown the walls
- back in 2013 when I started in UX, designers and devs were very siloed… we didn’t talk much to each other, and we often encouraged the stereotypes discussed earlier. One positive experience changed my perspective. If my journey can teach you anything, it’s that change starts with you. After my first experience with a developer, I began advocating for this kind of pairing on all of my projects. I shared my experiences with other designers and developers alike. Each opportunity I had to pair with a developer, I modelled the kind of partnership I wanted to have. Other designers did the same, and we began to see a drastic shift in the culture. The old, siloed ways of working were no more. Sometimes it requires a slow, steady effort, but don’t give up. The effort is worth it, because, let’s face it: designers and devs are much happier together.