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

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

Expand Messages
  • William Pietri
    Hi, Larry. From this, I wonder if you ve only encountered bad Agile implementations, which is totally plausible these days, but I think you re definitely
    Message 1 of 52 , Dec 6, 2010
    • 0 Attachment
      Hi, Larry. From this, I wonder if you've only encountered bad Agile implementations, which is totally plausible these days, but I think you're definitely missing what Agile methods can do for products and users.

      For example, if you take a look at the Lean Startup methods, which are derived in major part from Extreme Programming, it is an intensely customer- and user-centered approach. It is exactly the opposite of self-centered: its proponents continually tell practitioners to "get outside the building", and the core of the approach is a feedback loop between design hypotheses and examination of the impact on real users.

      Of course, as a company that sells design, I can see why you'd advocate against Agile approaches; they're much less amenable to the big up-front design approach that's the most convenient for you. But I think it's a business mistake for you to favor that. A waterfall-derived development approach has fundamental limits on speed of adaptation. That's already become unacceptable for more and more software projects. In the long term, there may still be parts of the design market that will still be ok with that, but it's not a way I'd want to bet.

      Of course, that's mainly your business. This one part, though, I take real exception to:

      What we really want to avoid is letting the developers design. They are developers, not designers, and waiting for them to design something then reacting to it is NOT what our clients pay us for. We are tasked with being proactive, not reactive.

      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. Most of them won't be as good at all times as a professional designer, but not every single design choice needs a professional designer at the peak of their powers.

      Well, actually, the way you've set it up, every design choice does need a professional designer, because the system you prefer keeps anybody else from learning how to do it. Team members don't get to work closely with good designers, and even if they did, they wouldn't be allowed to get any experience. They'll never learn, thereby confirming your beliefs.

      That is a system that is very convenient for companies that want to sell a lot of design, but I think it's not a particularly good system for making great software. Everybody should be doing design, by which I mean thinking about how their actions impact users and how to improve that.

      Agile methods, as deeply collaborative, feedback-driven approaches, are very amenable to making design thinking pervasive if that's what you want. That means better products. It also means happier teams, because it engages everybody in the work. And it even means happier designers: if they can trust the team to get the little things right, they can focus on the big, hard problems that made them become designers in the first place.

      William



      On 12/05/2010 04:50 PM, Larry M wrote:
      Rather than embed my answers to your good questions and making this reply quite long, I'll summarize my answers here, which, by the time I finished this, ended up being pretty long anyways. Sorry.   :^)
      
      To begin with, our firm pretty much does "design only," no development or graphic design. But to call it design only is a still a bit of a mis-statement. We perform all of the common UCD processes, such as user research, task analysis, usability testing, etc.
      
      We have observed many Agile teams implementing our designs over the years and by the time we have completed our design specs (wireframes) we have already addressed the usual design implementation issues. We involve the developers early and often throughout our process, as the design evolves from high-level design concepts to detailed design specs, to get their feedback on the feasibility of the design approach. This avoids the problem of finding out too late that a design can't be implemented.
      
      Getting a development team up to speed on this approach in one or two sprints is, I consider, a short time. How many years have we all struggled with trying to get developers to follow common UCD design approaches without success? In the past it took us years, and wasn't always successful.
      
      What we really want to avoid is letting the developers design. They are developers, not designers, and waiting for them to design something then reacting to it is NOT what our clients pay us for. We are tasked with being proactive, not reactive. Too often, a sprint is too short of a timeframe to adequately react to a poor design. 
      
      Given that our practice starts at the business and marketing objectives, and not at the screen/page design level, we perform a series of alignment reviews to make sure that the design directly relates to the key objectives. This includes task optimization and reviews with SME's and real users (as you know, they are NOT the same perspective <grin>), VERY early design concept reviews with users, and can include more formal usability testing. By the time we get to screen/page level design, we have identified the majority of the big issues and are usually only left with minor issues that can typically be corrected in a short sprint, such as deciding whether something should be a guided-discovery or progressive-disclosure interaction paradigm.
      
      One of the reasons we have formulated this Pre-Agile work is because most of this work cannot fit into a sprint. We usually have about 80% of the design work done before launching into the first design sprint. The sprints are where we complete the detailed design. The wireframes we deliver to the developers are (supposed to be) 100% complete. We leave the developers to the art of writing code, which is their chief skill, and they expect us to deliver tightly designed wireframes. Sometimes we fail to account for some logical loose thread that shows up in development, but that's why we interact with the development team.
      
      Some of the interesting benefits of having the design done "up front" is that it gives the team leader a better idea of how to parse out the development, and, since the UI design work is done, it dramatically increases the speed at which the developers can accomplish their work.
      
      In webapp projects, we try to get the browser issues ironed out well before we get into the wireframes. This is a good example of how to interact with the developers early on, to make sure we don't' design something that can't be supported.
      
      "I think everyone can do "better work" if they only have to consider 
      their "own work" than if they have to consider the whole flow."
      
      Interesting comment. Our whole approach is to AVOID forcing the rest of the company to bend to the development processes. When a company brings in Agile methods, they fail to recognize how these new processes affect the rest of the company's processes. Since development is producing releases as they go, this greatly affects how marketing must interact with development, prepare clients for the new release schedule, and market the releases. Training has to alter their processes, as do documentation, sales, customer support, etc. Our design spec deliverable actually makes it easier for marketing, sales, training, etc, to predict and plan for these releases. 
      
      Personally, I see Agile adoption as one of the most self-centered evolutions a company can embark upon. It serves only the development team at the expense of the rest of the company. Our goal is to find a way for everyone to benefit from this new development method, at the same time. By looking at the entire company, instead of just one department, we've learned that our approach works and it works well. As time goes on, I'm sure other methods will address the issue of company-wide integration, but for now, I'm sticking with this method.
      
      I hope that helped...
      
      Larry Marine
      
      --- In agile-usability@yahoogroups.com, George Dinwiddie <lists@...> wrote:
      
      Hi, Larry,
      
      I hear similar descriptions from time to time, and I'd like to ask a few 
      questions to flesh out my understanding of your situation.
      
      On 12/5/10 11:11 AM, Larry M wrote:
      
      We are a consulting firm and do things quite differently. I wonder if
      our different approach is due to being "outsiders" or is it because
      we perform our design services differently than the rest of the
      commenters.
      
      Does your firm do design only?
      
      
      Our team will spend a couple of months working together to define the
      problem that the product must solve, then spend a month or two
      creating the general, high-level design approach, with some input
      from development. This gets us to about 70-80% of the design. Then
      the team will jump into design sprints that is one cycle ahead of the
      development sprints. These sprints are usually attended by the visual
      design team, so that they can define the visual language. Its also
      common for the marketing folks to have visibility of this effort, as
      well, since they are responsible for aligning the product design to
      their marketing strategy.
      
      Note that design and development DO NOT occur at the same time. We do
      get design questions from the developers during development sprints,
      on occasion, but, for the most part, we deliver pretty good designs
      to the developers that don't generate a lot of questions.
      
      Have you observed the developers while they're implementing the design? 
        Have you asked them how easy the designs are to implement?
      
      
      There is usually a bit of a learning curve for the development team
      to pick up on design approaches, such as when to use lists verses
      radio buttons, but that usually only takes one or two sprints.
      
      Do you consider "one or two sprints" to be a short or a long time?
      
      
      What we have found is that Agile is a development environment, not a
      design process. Designing while you develop tends to lead to
      suboptimal design as much as it leads to suboptimal development. We
      try to get as much of the design done up front, even with early,
      low-fidelity testing, and then finish the details in the design
      sprints.
      
      Besides early low-fidelity testing, what other testing of the design do 
      you do?  Are these "design sprints" continuing a plan set out at the 
      beginning, or do they incorporate learning from after that initial plan? 
        If the latter, how do you gain that learning?
      
      
      One reason this succeeds is that we are not limited by the
      length of the development sprints to come up with appropriate
      designs. Some things just can't be done in 3 weeks. If you don't get
      the product off in the right direction, in the first place, it will
      never be able to meet its business objectives.
      
      BTW, our deliverable to the development team is a well defined set of
      wireframes and system behaviors. So far, EVERY team has said that our
      wireframes are the best specs they have ever received. The team
      leaders have also said that these specs make it much easier to parse
      up the development and to ensure that the product evolves as
      expected. Additionally, the rest of the company can do their work
      from these wireframes as well.
      
      What level of detail are these wireframes?  If you're doing web 
      development, how much similarity is required from browser to browser?
      
      
      One of the key problems introduced by adopting Agile development
      methods is that it forces the rest of the company to change how they
      operate. While Agile is good for development, it create new
      challenges for training, marketing, technical writing, etc. Completed
      wireframes allows every department to work in parallel so that when
      development delivers a new module, the rest of the company is ready
      to release it, as well.
      
      I guess my point is that UX folks can do better work if they are not
      buried in the development team.
      
      I think everyone can do "better work" if they only have to consider 
      their "own work" than if they have to consider the whole flow.
      
        - George
      
      -- 
        Dec. 14 - Agile Richmond in Glen Allen, VA
        http://georgedinwiddie.eventbrite.com/
        ----------------------------------------------------------------------
         * George Dinwiddie *                      http://blog.gdinwiddie.com
         Software Development                    http://www.idiacomputing.com
         Consultant and Coach                    http://www.agilemaryland.org
        ----------------------------------------------------------------------
      
      
      
      
      
      ------------------------------------
      
      Yahoo! Groups Links
      
      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/agile-usability/
      
      <*> Your email settings:
          Individual Email | Traditional
      
      <*> To change settings online go to:
          http://groups.yahoo.com/group/agile-usability/join
          (Yahoo! ID required)
      
      <*> To change settings via email:
          agile-usability-digest@yahoogroups.com 
          agile-usability-fullfeatured@yahoogroups.com
      
      <*> To unsubscribe from this group, send an email to:
          agile-usability-unsubscribe@yahoogroups.com
      
      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/
      
      

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