Re: [agile-usability] Re: where do your UX team-members sit?
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@...> wrote:
From: William Pietri <william@...>
Subject: Re: [agile-usability] Re: where do your UX team-members sit?
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.
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...
--- In email@example.com, George Dinwiddie <lists@...> wrote:
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
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
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.
Dec. 14 - Agile Richmond in Glen Allen, VA
* 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:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
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.