Re: [agile-usability] Re: where do your UX team-members sit?
On 12/06/2010 02:07 PM, Larry Marine wrote:
Quite interestingly, I see you dagmatic adherence to Agile and the notion that all people are exactly equal in skill and ability as rather Jurrasic. And if all you can provide are two weak examples of "development" success out of the tens of thousands of Agile efforts, then my much higher success ratio should cause you to pause and reconsider.
First, I'm hardly dogmatic. I'm happy to criticize Agile methods. In fact, I think the very first thing I said to you was lamenting the current state of Agile adoptions. And the blog post I've got in the hopper is on the decline and fall of the Agile movement.
Second, I did not say that all people are exactly equal in skill and ability, and in fact said just the opposite. I say enough dumb things without people having to make them up.
Third, your standard that I should name all of the successful Agile projects as examples, or stack enough up until I get to some magic ratio is absurd. I'm saying it can work. One example is sufficient proof that it can work well.
Fourth, I have no idea what your success ratio is, in that you haven't actually named any of your successes, and really, it's immaterial. As I said before, that you can succeed with your approach doesn't mean it cannot be improved.
I use dropbox and do not consider it a resounding success, nor a very complex product. And YouTube's success has VERY little to do with design, plus, again, it is not a complex product.
Dropbox has well over 6 million registered users and is making plenty of money. They started from nothing, and crushed their competition. That they spread purely through referral says that their users are pretty happy, too. You're welcome to have a different standard of success, but that is sufficient for them, and for a lot of other people.
YouTube's success has everything to do with user experience. They had a host of competitors, many of whom started earlier. The radically better user experience for viewers, uploaders, and especially for people sharing video through embedding made all the difference. Their CEO and founder was a designer, they made a big early investment in design, and design is still very important there, at least as of my last set of interviews at YouTube HQ. Since I was consulting for one of their (now-failed) competitors during the crucial period, I have paid a lot of attention to this.
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.
Well FYVM too, Larry. Because apparently all of my education and experience shows up with a quick Google search. And of course, who needs to engage with points when they can dismiss with a little ad hominem? Easy peasy.
Happily, it's not my job to educate you, so godspeed. I've got things to build, and users to satisfy.
But for people who are pursuing great products in an Agile environment, I still recommend whole teams, where everybody necessary to the product is physically close together. Since I believe in the power of design, I say that should include the designers as well.
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.