UX TEAM STRUCTURE: CENTRALISED OR EMBEDDED? A CASE STUDY OF THE PROS AND CONS.
•
5 likes•1,095 views
At Red Gate, we see usability and UX as our key differentiator. UX is in our DNA, and has been since the company had just 15 employees when we hired our first designer. Fast forward 10 years, and with 300 people working at Red Gate, we face new challenges in processes, management and organisation, all in a competitive landscape that's getting more challenging every day. So how do you scale a design team to work in this new environment? How do you organise a design team in a large-ish company? What works and what doesn't? I have been in the UX field for almost 20 years. As a designer myself, a manager of product and UX teams and a mentor of startups, I've seen UX organised in many different ways, from fully centralised design agencies to completely balanced teams. In this talk, I want to share my experience and dig into the lessons learnt from working at Amadeus and Red Gate.
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (20)
Similar to UX TEAM STRUCTURE: CENTRALISED OR EMBEDDED? A CASE STUDY OF THE PROS AND CONS.
Similar to UX TEAM STRUCTURE: CENTRALISED OR EMBEDDED? A CASE STUDY OF THE PROS AND CONS. (20)
Recently uploaded
Recently uploaded (20)
UX TEAM STRUCTURE: CENTRALISED OR EMBEDDED? A CASE STUDY OF THE PROS AND CONS.
- 1. Centralised or Embedded UX teams? A case study of pros and cons. UX Cambridge – 12 Sep 2014
- 2. Who am I? HEAD of UX at Designer Illustrator Mentor @miss_embe
- 3. My experience: 2 companies, 2 different eras... 1997 2K employees on Dev site 2007 96 employees 90 on site
- 4. My experience: 2 companies, 2 different eras... 2007 10K + employees (3K on site) 2014 290 employees (250 on site)
- 5. B2B customers Travel agents DBAs
- 6. Many point tools, not very integrated
- 7. ... and different in many respects.
- 8. ... and different in many respects.
- 9. ... and different in many respects. I am big and powerful. I own 33% of the market. My customers cannot not work with me. I am agile, and I usability!
- 10. Case study 1 – Embedded - Red Gate
- 11. Distributed UX: Small Dedicated team Dev, TEST, Tech com UX, MKT
- 12. Build and Maintain Ingeniously Simple Products
- 13. Deliverables: a very varied job.
- 14. Pros Extremely focused – Optimized for products
- 15. Pros No "them and us" it's a "we"culture
- 16. Pros Become an expert
- 17. Cons Hard to play on your strenghts
- 18. Cons Unicorns are hard to recruit – hard to scale copyright 2006 Electronic Arts Inc. All right reserved
- 19. Cons No one cares about the whole experience
- 20. Cons No global UX strategy
- 21. Case study 2 – Amadeus.
- 22. Amadeus
- 23. Amadeus organisation: organically, centralised You are here You work on this - About 20 dev teams - average 10 people/team - Product teams compete with each other - Little coordination between teams - About 1 to 17 designers - Little access to end users
- 24. Amadeus organisation: organically, centralised You are here You work on this - About 20 dev teams - average 10 people/team - Product teams compete with each other - Little coordination between teams - About 1 to 17 designers - Little access to end users
- 28. Create guidelines, training and certification.
- 30. Free up and spend more time on the big picture
- 31. Case study 3 – Red Gate again.
- 32. The goal: reaching the next level up in UX http://www.slideshare.net/UPABoston/ux-maturity-modelbuttiglieri
- 33. The goal: reaching the next level up in UX
- 34. Centralised UX: Red Gate The team is managed centrally (designers report to designers)…
- 35. Centralised UX: Red Gate …But at any point in time, they are part of a product / project.
- 36. Pros More skills and experience within the team.
- 37. Pros Pair design… AND also involve Dev teams
- 38. Pros Can plan/do upfront research on projects
- 39. Pros Managed by someone who knows your job.
- 40. Pros Active effort to grow skills: maps
- 41. Organise Katas and similar activities
- 42. Start new projects to demonstrate their value.
- 43. testimonials with an entire UX team available, you’ve been able to choose the right combination of people (and their skills) for the job. Project Managers were concerned that UX people would not be able to get the big picture/context unless they were embedded in the team – I don’t believe this has been an issue though. Ideally, not having dedicated UX people on the teams would mean the teams would take a bit more responsibility for the UX of the product. I don’t think this has happened I’ve seen more UX innovations happen since the reorg . I’m sure this is due to centralised UX and the ability to share and discuss ideas as a UX team.
- 44. Summary
- 45. PRO CONS Great UX, optimised for the team deliverable (eg. Product or feature) No Dev/UX rivalry Designer can become an domain expert Variety of the design job × No space to think about overall UX. × Difficult to play on individual strenghs. × Managers don’t understand designer works. × No real room for individual growth × Not an easy to scale organistation Manager understand their team. Team can manage resources / projects for best outcome (ie. plan research before dev, allocate right skills, etc.) Pair Designing capability. Greater team spirit. Ability to carve time to think strategically. More ability to grow individuals. × Product isn’t always optimised: have to make difficult prioritisation. × Risk to spread the team too thin. × Dev often not avaliable at research time. centralised embedded
- 47. One more parameter: where does the team report to? C - LEVEL CEO VP Dev VP Customer service Dev tech 1 Dev tech 2 doc training campaingns Prod. management Product 1 Product 2 Group 1 Group 2 UX Product 2 2 Product 1 Product 2 Group 1 Group 2 CTO CMO CDO
- 48. Best of both?
- 49. THANK YOU.
- 50. references and further reading • http://www.balancedteam.org/ • http://www.slideshare.net/UPABoston/ux-maturity-modelbuttiglieri • http://interactions.acm.org/archive/view/july-august-2014/collaboration-with-distributed- teams • http://interactions.acm.org/archive/view/january-february-2014/introducing-the- business-of-ux • https://www.linkedin.com/groups/Central-vs-distributed-UX-teams- 3735935.S.5870602121778327555
Editor's Notes
- The sort of Uis they buit when I joined, sort of software developed. Mainly API for Amadeus, and staring to make GUIs - jumped immediately to Web tech (!) Red gate was more established in the UI design.
- A main difference is the attitude towards usability.
- At the time, Red Gate business model what very much treating a B2B like a B2C: so Usability was very important for the model "try and buy"
- About 2 years I joined Red Gate, was the big wave of Agile movement so we started to use a variation of its methodology. We also organised teams around customers types, so that we’d balance our effort and prioritise. Typically, a division will have Small teams: Project manager manages all the « dev » functions, typically: 2-3 Developers, 1-3 Testers, 1 Tech Author, 1 Marketing person, 1 UX person. In the team (managed differently? – to check!) there is also 1-2 sales people and 1-2 support people. All team members are managed by the product manager, who gets his reaquirement from the product manager. The teams tend to stay fixed (ie. No much turn over) Role of the Designer/UX specialist in the team is to make the best product as possible for the target audience: make it usable. Design and test.
- It means the designer is responsible for many deliverables: Test Wireframes Me-fi Follow up the dev when its happening. No constraints: do what’d best for the team. We designed and build products, the website, the doc etc. Trying different methods and tools. We’ve built a lot of point tools. Depending on the maturity of the product you are working on, we delivers full storied or wireframes. Personas, etc. The product had nothig to do with other products.
- This organisation allow the team to be extremely focused to the project / product at end. Designer attend standups, everyone work on the same thing. It is easier to work with dev and engage them to help design. Can be influencial in the product direction. “The UX person understands the problem in much more depth because of day to day communication. Hence, it is easy for them to design. There can be occasions when team has not asked for help but UX person can spot the need for UX and hence interfere.” o examples are obvious: prnciple of scrum and lean startup. When everyone works on the same thing, it is easier to engage dev. o simultenaously of tasks means it is easier to engage your dev team. e product direction within the boudary of the products (isn’t part of the priorotisation)
- Team has some autonomy to manage their destiny. There is no Dev vs Design team (and all the others) this means we are all in it together, and we are trying to solve the same problem Strong team identity, per product. There is the potential to work as a balanced team. I am saying ‘potential’, because this organisation allow for it, but it isn’t quite working that way. We had both cases in different organisation, where desinger was working as part of the team (eg. APP) … or less so (eg. Backup) Personality play a big part, there. The UX person understands the problem in much more depth because of day to day communication. Hence, it is easy for them to design. There can be occasions when team has not asked for help but UX person can spot the need for UX and hence interfere.
- Assuming the team stays constent, you aquire a great DOMAIN knowledge. There is a great transfer of knowledge within the team, ans you speak to mainy users of the system. Overall, you should become better at .
- Every individual need to do a bit of everything, even if it isn’t playing on their strenght. Not only that, but you have to work on 2 sprints: preparing design for the next one, and supporting dev on the current one. Individual work in isolation from their peers; When you are a junior, it is difficult to be trained properly. You don’t play on your strenght if you are not a unicorn The design can be restricted by the skills of the person. E.g. if the person is good in interaction design but not so good in visual design then the design will reflect it. Person can become bottleneck for project. Thats not great for a product team, but it is even worse at the company level
- It is easier to train a horse to become one, if they want to That’s already bad for the team, but it isn’t great for the company.
- And without thinking about the real « whole expérience » just some small issues like « bundling products » is hard. No forward thinking (although that’s maybe down the the tam The company doesn’t supports projects that aren’t product related (ie. What’s perceive to bring value) and every division would have a different priority at the time… so it is hard to make « common » things happen. For example, who is in charge of the shopping basket and upsell experience? Some teams would like sign up to happen differently (no email, for instance)
- Instead of working on the one to one mapping of the central system, we could take a step back and design and test a more efficient/ intuitive system. It wasn’t developped yet, but we presented and sold it to big account, thus forcing the company to implement some of it
- About 1 year ago, Red Gate has been restructured around some of the issues we’ve highlighted before. The lack of direction wasn’t always a UX thing, it was global. They’d appointed Full time functional heads (like me) to support the business and we influenced the organisation a little. We took the opportunity of the reorg to try and address some issues we had before. From the business view point, we must « delight our customers » (in fact, we have a division called customer delight) and have a set of tools that will work seamlessly together, and that will allow our customers to do
- And we started to work on the predicatbility of the experience.
- The team is managed centrally (designer report to designers)
- But at any point in time, they are lent to a product / project.
- This means the team can organise where the members will spend they time: Do we need research? What sort? Do we need HTML knowledge? People can pair, like we’ve seen before to achieve better outcome. Better team spirit * Still have some collaboration with dev (via meeting, phone,workshop etc) * after a while, the team become an "entity" so when reorg happen, you are still together, hopefully in a better place in the organistion.
- This organisation works well, because it allow us to have the advantage of an embedded team and centralise team. But also, we are involving the dev teams in the design process (see Revathi presentation, form yesterday)
- Because we are out of the project teams initially, we can talk to product managers before the projects are planned so we can anticipate what research needs to be done prior dev start.
- This means individual can learn from their managers And thats important because we can grow and develop stuff.
- Questions?