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

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

Expand Messages
  • William Pietri
    ... That s still a binary construction, which I also think is bunk. It is a continuum. There are some design choices that any idiot can make. There are some
    Message 1 of 52 , Dec 6, 2010
    • 0 Attachment
      On 12/06/2010 08:48 AM, scott wrote:
      This is the eloi/morlock approach to design, and it's bunk. Developers 
      aren't some mysterious subhuman race; they're actual people, who can 
      indeed learn to make good design choices. 
      
      Sure, but when they have the training and experience to make good design choices they will be designers (as well as developers), and that's fine. For me, it's about skills rather than about titles.
      

      That's still a binary construction, which I also think is bunk. It is a continuum. There are some design choices that any idiot can make. There are some that only the world's greatest designers can make. Strongly iterative and collaborative approaches increase both individual and team design competence.

      However, there's another point in Larry's paragraph that's important. A designer, concentrating only on the design, can iterate that design a lot faster than a designer plus a developer can iterate a design-as-implementation. From the client's point of view, that gives them a much earlier feedback point. And clients tend to want to be able to react to a broad design - an overall design for a site or application, rather than just the narrow slice that the team does in its first sprint.
      

      First, that clients want something doesn't say anything about whether that's good for products, users, or teams. I'm interested in the latter. That others are in a line of work that encourages tradeoffs between the two is not a problem of Agile methods.

      Second, as far as I can tell, nobody here thinks design should only happen as part of changing implementations, so that's a straw man.

      Third, iterating a design has no value on its own. The only time design has value is when it impacts actual users. People can do some design without shipping and seeing what happens, but one can't do all of it that way. And even if you could, it less and less makes sense to do it that way. Some teams now release more than 50x per day, meaning releases can be effectively free.

      So yes, by all means, designers should iterate, and think broadly about design. Nobody sensible is opposed to that. But that doesn't mean you have to do BDUF, or that you can't ship early and often.

      William

    • 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
      • 0 Attachment
        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.