Adrian Howard — Fri, 07 Jan 2011 19:49:26 GMT

On the “Separate modeling from design” point – you might want to take a look at what folk from the development side are doing with concepts like “ubiquitous language” and Domain Driven Design. They’re using different words and coming from a different background, but with much the same sort of aims. There’s a lot more common ground between UX folk and dev folk than many realise – and a lot of it sits at this sort of level. The abstractions that the designer discovers should be the same ones that get implemented in the code.

On “Design literacy” & “Collaborative Design” – oh god yes. And I’m so glad to see you say it. I encounter far too many designers who seem to get very nervous letting any control on the design move out to the rest of the team. It’s a foolish fear. Some of the stuff we do _is_ easy. The more people who know the basics, the more time you get to spend tearing your hair out with the problems that are actually difficult :-)

(Oh and @bfriesen “Agile was developed as a method of cranking out software quickly for the sake of monetary gain, NOT for the benefit of those who would ultimately have to use it.” – That doesn’t bear much relation to how I understand Agile to have come about – or be practiced by good Agile teams. Quite the opposite. The focus was producing quality. The “quickly” aspect was only because the process was cutting back on wasteful process and introducing more effective feedback mechanisms which meant that the good bits of the software got delivered earlier in the process. The Agile==Quick meme is something that needs to be stamped out. It’s wrong. Quick isn’t the goal. Quality is.)

Adrian Howard — Thu, 20 May 2010 12:00:21 GMT

Totally agree that it’s a team problem – and that it takes a team approach to solving it.

Generally though most of my problems seem to come from the anti-Nathan.

Anti-Nate is really passionate about the chores. Understands that they’re vital. Understands deeply and personally the result of those chores not being done and done well.

Unfortunately Anti-Nate doesn’t really trust anybody else to do the chores as well as he can. Doesn’t really trust anybody to even _help_. Because of this Anti-Nate spends all of his time doing the chores in his own particular grumpy way, complaining that nobody else cares.

It’s _obvious_ to Anti-Nate why the chores are important. He things everybody understands this too; that the people who don’t want to get the chores done are just lazy.

He doesn’t see that he’s often blocking other people learning to do the chores and understanding why they’re important.

I don’t encounter many Nathan types in the workplace – the people who only want to do the fun stuff. My experience has generally been that everybody wants to make a good product – and are more than willing to do fun and non-fun things to do it.

There’s washing up and axe throwing a plenty in development and in user experience!

When I do encounter Nathan’s they seem fairly easy to manage. The team doesn’t like freeloaders… so you can educate or remove ‘em.

Anti-Nate’s are much harder to manage. They’re really good at their job and usually a vital part of the team. They’re passionate about the product being successful – but they’re unwillingness to let go of their particular area of expertise they make the team as a whole less effective.

It’s easier to deal with an Anti-Nate when you have a group of people with vaguely similar skills. You have people to translate and mediate. You can start a process of spreading the knowledge around quite easily to people with similar skill sets.

When they’re the only person with that particular skill set however – they can become a real blocker to effective work being done. If you have an Anti-Nate product owner, or an single Anti-Nate DBA, or a lone Anti-Nate UX expert… problems ensure.

If UX isn’t integrating well due to Anti-Nates, I’m willing to bet the many developers are less likely to be the culprits than the few UXers. Just playing the odds… :-)

Still a team problems. Just one of a different kind.

Thinking and Making: Comments by Adrian Howard