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

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

Expand Messages
  • Larry Marine
    Damn! It wasn t intended to be condescending. Electronic communication is a totally frustrating user-experience. Larry Marine ... From: Dave Rooney
    Message 1 of 52 , Dec 6, 2010
      Damn! It wasn't intended to be condescending. Electronic communication is a totally frustrating user-experience.

      Larry Marine

      --- On Mon, 12/6/10, Dave Rooney <dave.rooney@...> wrote:

      From: Dave Rooney <dave.rooney@...>
      Subject: Re: [agile-usability] Re: where do your UX team-members sit?
      To: agile-usability@yahoogroups.com
      Date: Monday, December 6, 2010, 4:28 PM


      Wow, Larry... I believe you've just written the most condescending
      message I've ever seen. Way to keep the communication going.

      Just wow.
      Dave Rooney
      Westboro Systems
      Web: http://www.WestboroSystems.com
      Blog: http://practicalagility.blogspot.com
      Twitter: daverooneyca

      On 06/12/2010 5:18 PM, Larry Marine wrote:
      > BTW, it occurred to me to review your pedigree, William. You have a
      > notable background in technology, but until you have some real
      > education and experience in established UX design practices, you can
      > really only speak from that one perspective. I've enjoyed our
      > discussion, as it has helped me see my approach from your
      > perspective, and your perspective is the kind that I must integrate
      > with, regularly, if we are to succeed in constantly improving design
      > AND development processes.
      > Larry Marine
      > --- On *Mon, 12/6/10, William Pietri /<william@...>/* wrote:
      > From: William Pietri <william@...> Subject: Re:
      > [agile-usability] Re: where do your UX team-members sit? To:
      > agile-usability@yahoogroups.com Date: Monday, December 6, 2010, 2:40
      > PM
      > Hi, Larry. I'm not saying you're against Agile methods. I'm saying
      > you're in the tv-is-radio-with-pictures stage of understanding them,
      > and in particular the way they can enable better design.
      > I believe you're wrong that Agile approaches force anything on the
      > rest of the organization. There are plenty of Agile teams, especially
      > in the contract development world, where Agile adoption ends with the
      > product/project manager. Internally they're very agile; externally,
      > they execute to spec and timeline.
      > What Agile methods do is offer opportunities that weren't there
      > before. The opportunity to better manage schedule issues. The
      > opportunity to change priorities mid-stream. Opportunities to ship
      > sooner, respond to competitors, and execute with higher quality. And
      > to produce better-designed products for less money.
      > It's true that they aren't design processes, because not all software
      > needs much design, and because their origin was in that end of the
      > field. But you can happily marry them with good design, as has been
      > happening for quite some time. One formalization of that is the Lean
      > Startup approach.
      > I continue to disagree with your notion that developers and designers
      > are somehow fundamentally different human beings, utterly unable to
      > partake of one another's natures. It's bunk, and there are plenty of
      > counterexamples. E.g., I recently heard the folks at DropBox speak.
      > They crushed every other file sharing service out there through
      > superior user experience, and it was all done by developers. Or take
      > YouTube. They got paid $1.65 billion based mainly on the user
      > experience, and there programmers and designers work very closely,
      > with developers happily participating in the design process.
      > And it works both ways. One of the best designers I've ever worked
      > with, visual and UX both, is also a perfectly competent coder. He
      > likes it for the same reason that painters don't just design
      > paintings: his medium is software, so naturally he'd learn how to
      > make it go. He works happily with more serious developers for
      > especially serious code, but he does it in the spirit of
      > collaboration, not delegation.
      > And that ignores the smaller bits of design and development that go
      > back and forth all the time. A developer writes a little copy and lay
      > out some menus. A designer tinkers with the HTML and CSS. Maybe they
      > do it side by side, giving each other tips. And certainly they end up
      > seeing one another's work and reviewing it within hours.
      > I agree achieving that is difficult in the environments you describe.
      > But that's only because they aren't set up for learning and
      > collaboration. Done right, a tight Agile team is great at that. That
      > is not to say that developers become perfect designers, or designers
      > become perfect developers. But what you do get is a much more fluid
      > division of work, which results in a better product for less money
      > and pain.
      > As to not arguing with success, that's a terrible argument for
      > somebody in software to make. There's very little that people do
      > today with software that is fundamentally novel. We just do it
      > better, faster, and cheaper. And then we come back and do it again.
      > The whole history of our field is arguing with success until the
      > masses say, "Oh, now I see what you mean."
      > I think it's our obligation to argue with success, because that's how
      > progress is made. If you like your current method, by all means stick
      > with it. I'm not saying you have to do better. I am saying, though,
      > that you can do better, by taking advantage of the opportunities that
      > Agile approaches offer.
      > William
      > On 12/06/2010 10:45 AM, Larry Marine wrote:
      > > Yes, I would have to say that the nature of our business is sort of
      > > a self-selecting mechanism in that a successful product team, agile
      > > or otherwise, is not likely to call us. So, we am most likely only
      > > going to see poorly implemented Agile efforts.
      > >
      > > BTW, by self-centered, I was referring to the notion that, by
      > > moving to Agile methodologies, a development department forces the
      > > rest of the company to adjust their processes to fit with how they,
      > > the development team, will work in the new methodology. Agile
      > > methods impact the entire company, and little thought or effort is
      > > given to address this prior to adopting Agile methods.
      > >
      > > Also, I find it interesting that you think I am against Agile
      > > methods. I’m sorry it came across that way. That is certainly not
      > > the case. We really don’t’ care, one way or the other, how
      > > developers work. We focus on how to help companies produce a more
      > > successful product and how to integrate a more successful design
      > > process with development.
      > >
      > > I was once a developer and have written millions of lines of code
      > > in about 20 different languages, from machine level to C++, so I do
      > > understand developers to a greater degree than your comments
      > > suggest. I earned my degree in Cognitive Science from Don Norman at
      > > UCSD while working as a developer and learned a different way of
      > > thinking that I continue to use as a UX designer. My assertion that
      > > developers are NOT designers is based on my deep understanding and
      > > experience of both disciplines.
      > >
      > > I also firmly believe that while it is possible to educate a
      > > developer to think like a designer, it is highly improbable. Part
      > > of that assertion is due to the fact that as a developer, you have
      > > to think a certain way that is often counter to how you need to
      > > approach design from a UX perspective. I also don’t think a UX
      > > designer makes a good developer, either, They are two distinct and
      > > valuable skills that complement each other. Its no different than
      > > expecting a developer to be a skilled graphic designer, or vice
      > > versa. Again, two distinct yet complementary skills.
      > >
      > > The way we operate works and it works well. We focus on getting the
      > > right resources to do the right things. Yes, developers CAN design
      > > screens, but our experience is that those developer designed
      > > products never achieve the successes that companies expect. So,
      > > what’s wrong with letting the designers design the screens and the
      > > developers develop the code? You can’t argue with success, and we
      > > have helped over a dozen companies, not just succeed, but dominate
      > > their markets. It would be easy to say that those successes are due
      > > to some exceptional skill we posses, but the truth is that the
      > > processes we bring to bear are more to blame for those successes.
      > >
      > > The key point I want to make here is that Agile is a DEVELOPMNET
      > > process, not a design process. We have adjusted our DESIGN
      > > processes to integrate well with Agile methods. So, with our
      > > integration, we have complementary DESIGN and DEVELOPMENT processes
      > > that create phenomenal successes. What’s wrong with that?
      > >
      > > Larry Marine
      > >
      > >
      > > --- On *Mon, 12/6/10, William Pietri /<william@...>
      > > </mc/compose?to=william@...>/* wrote:
      > >
      > >
      > > From: William Pietri <william@...>
      > > </mc/compose?to=william@...> Subject: Re: [agile-usability]
      > > Re: where do your UX team-members sit? To:
      > > agile-usability@yahoogroups.com
      > > </mc/compose?to=agile-usability@yahoogroups.com> Date: Monday,
      > > December 6, 2010, 9:03 AM
      > >
      > >
      > >
      > > 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
      > >>
      > >> http://groups.yahoo.com/group/agile-usability/join (Yahoo! ID
      > >> required)
      > >>
      > >>
      > >

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