Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] where do your UX team-members sit?

Expand Messages
  • Rob Park
    I am currently working with a team that has a dedicated UX specialist. She sits with the team itself. This company is used to having the UX people do a lot
    Message 1 of 52 , Dec 5, 2010

      I am currently working with a team that has a dedicated UX specialist.  She sits with the team itself.  This company is used to having the UX people do a lot of up-front work, so it's some change for them.  But we are about to release to production, where traditionally the UX design would just be wrapping up.

      With this team it's so important that the UX specialist be with the team:  

        * She can't get the workflow all correct by herself.  Many decisions have been and continue to be dependent on what's currently implemented and only what will be implemented by the time of the feature being designed.  (It's also important that the whole team understand the issues, which they do because they're involved... not a different UX team.)

        * Often, there is a difference between what the web devs produce and what the Photoshop mockups suggest.  In these cases, the UX specialist must pair-up with the devs and get something working they both like.  There are of course a lot of considerations of time to implement different options and the product team is generally involved then too.

        * UX is a step/column in our Kanban system.  We record the number of changes that occur when at that step.  The goal is to be aware and include enough UX early (per story) in order to minimize the number of changes needed by UX.

        * We've expanded our "3 amigos" (biz+test+dev) to include UX as the "fantastic 4". :)

      On another team that I worked with last year, the UX specialist sat with the team there too.  The project involved delivering PDFs to thousands of customers and there were strict guidelines as well as strong desires about the look and feel for this corporate communication. It was critical that UX was with the team.  Devs would often have to figure out how they were going to deliver certain data first, but then (again per story) they would confirm and conform the UX layout... most importantly ironing out any gaps at that point.

      There was a strict deadline on the delivery, so whatever we had on that date was what was going out, so leaving UX until the end wouldn't have worked (which I would assume is generally the case with incremental delivery to production).  In this case, the layout was generally conceived up front, but as always there were compromises that had to be made on many stories.  Cases that weren't considered initially and cases where the data we had didn't match what we thought we'd get.  It worked perfectly being able to address each situation 1 at a time with a person who was immediately available and actually part of the team.







      On Fri, Dec 3, 2010 at 12:22 PM, yaniv_nord <yanivnord@...> wrote:

      I manage a team of 4 UX folks at a medium sized software company that has recently transitioned to Scrum.

      We have 3 scrum teams each staffed with Developers, UX, QA, Scrum-master and product owner. So the UX people sit with their team.

      For the most part this is ok for me, but I worry that we're missing out on that really important UX process that comes when you get a few smart designers in a room bouncing ideas off one another.

      My instinct is to huddle the UX team together.

      What are your experiences with this issue?


    • Kristen Ryan
      I work at a medium sized company. We have three designers and five developers, all who sit in close confines. From reading the posts lately I wonder if we
      Message 52 of 52 , Feb 9, 2011
        I work at a medium sized company. We have three designers and five developers, all who sit in close confines. From reading the posts lately I wonder if we handle design and development differently.

        It seems (and I may be horribly wrong) that the arguments are mainly against big, up front design. I absolutely agree. However, I don't think that having designers do designs prior to development is a bad thing, if done well and there's plenty of communication.

        We have one month release cycles, which means we're getting real, working software into our clients hands very quickly, and get feedback quickly as well. We do paired design, so two designers will sit down and shake out most of the design. This can take anywhere from a day to a week and a half depending on the size of the story. During this time we meet with developers several times so they know where the design is going, point out technical road blocks, and yes, give design input. Then we hand it over to get coded, and during this time the designers work closely with the developer who's handling the story to answer questions and work out real time design questions.

        So the designers do a bulk of the design (I'd say 95%), but there's no huge outlay of up front design. We do it all 'just in time'. Designs get input from developers, product owners, and other stakeholders. The mock up's may go through three or four iterations before they reach development, all within a few days time.

        I'm not saying that developers cannot design, I think many can to varying degrees. We've just found that paired design done just prior to development, and working in close proximity to each other has allowed us to create great designs quickly.

        On 12/4/10 4:33 PM, Tref Gare wrote:

        Our environment is the opposite – we huddle our ux folk together which does give us the cross pollination thing, but means we miss out on the embedded engagement with the developers.  I’d love to find some form of middle ground where I get to regularly mind meld with my design colleagues, but also am in there with the devs when the design hits the metal.

      Your message has been successfully submitted and would be delivered to recipients shortly.