6

I manage a UX team of 10 designers working within an agile software development company. The team are located together in the same area but each designer works with a different agile scrum team. I'm facing the following problem:

  • Designers feel they do not have a good grasp or idea of what other members of the design team are working on.

We have a weekly meeting for 2 hours where all designers get together and give updates. Some designers show some things they have done and others just give more general updates without visuals.

Because there are 10 designers, it takes some time to go around everyone and the meeting in general seems a little stale. Even with this in place designers dont feel they get a good enough overview of what others are doing and the process of going around one by one seems tedious.

I've also tried taking over a wall in the office where each designer has a spot to update their space with designs and progress they have made. However, this space is located a little outside the area and many designers forget to do it and feels like alot of management. I think something like this would work well of integrated into the design space, but at the moment that is not an option.

I'd be interested in hearing any ideas or other possible techniques I could employ to make the sharing of work a little more fun, effective and integrated into the team. Any forms of collaborative methods or ideas welcome.

Thanks!

  • have you tried slack? – icc97 Feb 6 '16 at 21:31
  • 1
    If each designer is working with a different team, why do they need to know what the others are working on? Unless they are just resources allocated to projects and need to shift around. Also, I think with that many people the standards and processes will be more important than just communication and tools alone. I think one of the best ways to get people talking and sharing is to discuss design issues they come across in the project and brainstorm with other designers. – Michael Lai Feb 8 '16 at 1:49
8

Reframe this: it's a great opportunity!

enter image description here

The obvious way to interpret your situation is...

The team has a hard time keeping in touch because individuals are off in project-land, each assigned to different project. As a result fragmentation and isolation happens and I'd like a way to avoid that and promote sharing and team spirit.

This view of the situation is likely to lead to ineffective solutions because you are trying to "fix a problem"...so at best you end up plugging a hole or "avoid bad team dynamics".

A more constructive way of framing this is...

My team has a unique and desireable opportunity to gather experience and evolve faster than most other UX teams, because each member spends meaningful time immersed in different cross-functional teams, working on different products. This creates an enormous surface area of learning and exposure to the organization that could really boost the experience curve of the UX team as a whole.

By understanding the positives aspects of your team's configuration, you are more likely to come up with solutions that leverage these positives rather than just plug the negatives.


For example...

Recognizing the positive qualities of your situation (broad learning surface, cross-functional contact, multiple product streams), some of the following may fit into the contours of your organization:

  • Design peer reviews - Have your designers regularly pair up and peer-review their work. Since each pair is working in 2 different teams, they can cross-pollinate ideas, provide "outside eyes" to prevent design "tunnel vision", and connect more intimately through one-on-one peer sessions rather than a group share-fest. This will in the end make them better designers and should improve their work product. Peer reviews also provide solo designers on a project with:

    • A sense of professional accountability to their peers
    • Some design team support for "designer vs the team" issues...eg. if a designer is arguing for a different color scheme or layout, having another designer peer-review the issue may help provide more firepower for the designer to make the case convincingly to their scrum team.
  • Institutional learning process - You have a broad surface area of learning, so think about ways to properly institutionalize that learning. Doing weekly play-by-plays on projects is boring and ineffective. It may be much better to ask all designers to do a standard post-mortem after each project...this is more likely to elicit interest since it focuses on a proud showcase of the project's highlights:

    • Show-and-tell the most interesting design problems in the project.
    • Articulate why and how design made a difference in the product.
    • Think about lessons learned for the UX team coming out of the project (how can we advance the capabilities of the team?)
    • Mention any books or new UX concepts learned in the process that folks may want to look into (e.g. "we used React Native and it was great" or "we found a great tool for A/B testing")
  • Celebrate the staffing model as part of your team strengths - You can even pitch recruits by noting that designers get to work across multiple products and teams, and so will learn much faster as well as get exposure to cross-disciplinary skillsets and decision processes. This is a pretty attractive proposition for young designers who want to get experience quickly.
  • Staff the rotations to promote career development - Since team assignments are part of the organizational structure, you can't avoid them for now, but you can ensure that team members get a solid cross-section of exposure over time to make them better rounded UX professionals. i.e. if a designer has had 2 mobile app assignments, you may want to rotate them into a physical product assignment to provide some learning opportunities and variety for the designer.
  • Use process and records to promote institutional memory - Keep case files for project design post-mortems (print the showcases into standard books, for example)...these are great for folks to flip through for inspiration or to remind themselves of what the team learned.
  • Use real-time tools judiciously - Slack can be a real time sink and distraction to designers seeking to balance real project responsibilities against UX team participation. Slack or IM can be effective for team help, e.g. "can anyone help me automate an illustrator workflow?" but these platforms can devolve quickly so it's helpful to provide some social norms or moderation to prevent them from swamping the team with useless banter.

...there are many more examples, but hopefully this is a helpful start.

3

In our company we have a monthly stand ups for sharing project updates among teamleaders. This works quite good as there is always enough news to tell. And it does not take too much time too often - around one hour.

May be you try two tracks, one weekly 5 minutes update each member and a monthly 10-15 minutes update with slides or images in form of a little presentation.

Or you do a monthly 3 hours in-house summit where everyone prints a poster with his/ her project and gives a poster presentation as seen at some conferences: first walkaround and later presentation in little groups.

Hope the suggestions will help

  • Thats a really nice idea and focus on the larger updates less frequently. Thanks for that. – UXG Feb 6 '16 at 22:34
3

Interesting, I am about to join such a group (starting tomorrow, actually), so I was hoping for a huge discussion here :-)

From my frontend experience, I would try the following:

  1. Splitting the group in two halves, say, Blues and Reds. Let them present separately one day per week. This will also bump up the team spirit.

  2. Gamify presenting with visuals: one report == 1 point, one presentation == 5 points, 20 points == free beer/beverage of choice.

  3. Meet up for a brainstorming session — not for presenting but for helping each others with blockers. This should reveal who is good at what and who is falling behind.

  4. Have a slack channel to bounce off interesting links and funny stuff. This will improve the spirit and communication.

  5. Find a charismatic leader, someone with sense of humor within the team and consult with them how to improve the situation, maybe they will have an idea or two.

  6. I personally feel much better if I have time to have fun with my personal areas of interest when I am blocked by something at work. Some of the best frontent devs I've seen seem to be that way, too. So I'd suggest to give each designer a 10% of the time for a personal project and let them present it every month or two.

2

Online tools such as Slack and Asana can really help with team communication and collaboration. In your situation, it would enable any member of the team to see at what stage other parts of the project(s) are. As it can also be used as a replacement for internal email, it is more likely to be kept up-to-date than a physical board that may be less obviously accessible.

  • We use slack already on the team and it's great. I've heard of Asana but havent looked into it in detail. I might see what it's about and trial it. Thanks for your thoughts. – UXG Feb 6 '16 at 22:35
1

See if you can organize your team around 2-3 common missions or objectives? Split your team into 2-3 mission-based sub-teams and identify a point-person for each mission (for example "team process simplification", "team delight", etc.). Make the point-persons responsible for certain mission-specific KPIs. Rotate team leads every couple of weeks or months to increase cross-collaboration.

Another version of this would be to identify a couple of leaders with unique skill-sets on your team (visual, iXD, research...) and give them a mandate to oversee each aspect of those areas across other teams. This would increase levels of collaboration between the designers on your team and also raise the level of overall design quality across the entire organization.

If this is beyond your scope as a leader, and you're looking for a quick fix, you can try scheduling daily design huddles. 30-60 sec (1st thing in the morning) for each designer (make it a hard stop) to give an update on what they're planning to do that specific day.

Also, if your "design wall" is too far from your space, buy some large foam-core boards and use those to showcase work.

Hope this helps.

1

I work at a company that has UX pods in a lot of different teams. In the pod I work in, the UX designers often work on different projects. We have a weekly pod meeting and everyone has the opportunity to discuss/share what they are working on. We also have an overall UX staff meeting once a month. The individual contributors have the option to present their recent work to the entire group as well. In addition, my current manager has paired each Sr. UX designer up with 2 Jr. designers. We meet 1x a week and brainstorm.

0

As you describe it, it's not "a team" but a number of pros assigned to work in parallel different maybe independent missions.
One way to make a team out of that people would be to serialize work, instead of doing it in parallel.

Let me explain myself:
I'm suggesting that the whole team (or two half-teams) fucused in a single project (or two) for a short period, in order to do great things, the things that come ont of great teams, instead of doing simple graphical design directed by each project's PM, who will ultimately end up shaping the UI's usability.

The whole team is more powerful, has more weight inside the company than the isolated designer.
The team is powerful enough as to successfully foster policies tending to build usable UIs from the outset, "usable by design" as I like to say.

The team activities can be UX-specific tasks, like certifying a design against a company policy, doing simple user testing, also presenting a design to a bunch of managers and clients (instead of letting the lone designer fight that battle).
It must be tasks that the dev team is unable to perform.

After a while, success would be to have a teams lineup asking for a "UX bath" or whatever you name it.

What you must not do is to have joint design sessions. Design must be done in isolation, and only discussed publicly when it has got it's shape.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.