Introducing design to a dev team for the firsttime

22 May 2008 - 6:58pm
6 years ago
2 replies
398 reads
Scott Berkun
2008

I'm surprised by the advice on this thread, especially yours here James.
Talk to the CEO? Why? As Martin explained he's been asked to be more active,
not to stage a coup, which is exactly how most of the people in line between
Martin and his CEO would see this sort of thing.

Worse, most of the other advice has advocated about 20 lbs. of process and
evangalism without asking if all that's needed is an ounce of results.

First and formost: Martin, if you are a self admitted wanna-be, the best
thing you can do is to advocate hiring a professional. If you are not
confident in your ability, rookie mistakes run the risk of ruining your orgs
perception of what a qualified pro can do.

Second: the goal is to make better GUIs, right? That becomes straightforward
if you are granted the power to write the first spec, make the first
screenshots, and have your boss rallying the development team to make the
first prototypes based on your designs. Tons of usability studies, daily
whiteboard sessions, or most of the processes mentioned become unnecessary
if you have authority from the begining and the expertise to set the right
course from day one. Most bad GUIs suffer from the same two dozen or so
mistakes - you don't need to be a design maestro to correct or prevent them.

Third: If you have trouble getting support from programmers, go to your boss
and ask for more ammo. If the team has never seen a usability study, it can
be a great way to get their attention and support, but if your UI problems
are basic, you won't be learning much from them - they're more for the team
than for you.

Many programmers don't care much about UI design one way or the other -
really they dont - what they care about is having a clear spec to work from
that makes sense. If you write better specs (in their opinion) than the
other guy, and your specs happen to have been UI designs in them, they be
building better UIs without even noticing.

Lastly, as far as where to start. Get involved early. Ask for authority over
any screens and specifications. Pick one or two of the best programmers out
of the bunch and ask them what you can do to get their support (they often
have more power than the managers do). Buy a dozen copies of GUI bloopers by
Jeff Johnson and put them on the chairs of anyone that writes UI code, with
a post-it note saying "Please please please read this". Most of the rest
will take care of itself. Pick small easy clear wins and repeat. Once you've
proven you can deliver and have earned a positive reputation, only then look
to expand. Only then do internal marketing, using your proven wins as the
argument for why even more people should follow your lead.

-Scott

Scott Berkun
www.scottberkun.com

----- Original Message -----
From: "james horgan" <horganjames at gmail.com>
Cc: "IXDA list" <discuss at ixda.org>
Sent: Thursday, May 22, 2008 1:19 PM
Subject: Re: [IxDA Discuss] Introducing design to a dev team for the
firsttime

> Hi Martin, I'd talk to your CEO or whoever is in charge, show them before
> and after scenarios and make a case as to why you think usability =
> increased revenue. I would also do a bit of internal marketing, ensure
> your
> team are referred to as interaction designer (never graphic designers) and
> do some educational sessions on why preplanning and information
> architecture
> add to the product and is something everyone can support.
> You have to solve the internal attitude to it before you (and your
> coworkers) can educate the client. I would research industrial
> design history and how they got into the mix (they were seen as glorified
> prettifiers before).
> hope that helps.
> james

Comments

23 May 2008 - 1:43am
martinpolley
2007

Hi Scott,

First and formost: Martin, if you are a self admitted wanna-be, the best
> thing you can do is to advocate hiring a professional.

Well, I am here already so it's not going to cost them much to use me for
this. Certainly much less than brining someone else in from outside,
justifying budget, etc. And at this stage it's just a few new screens for an
existing webapp. If it comes out any better than what they would have come
up with on their own, it's a win. (And I really, really WANT to do this! And
I'm not a *complete *amateur—I have done a ton of reading, podcast
listening, etc., and I have already given them feedback on existing
products, which was appreciated and acted upon.)

Second: the goal is to make better GUIs, right? That becomes straightforward
> if you are granted the power to write the first spec, make the first
> screenshots, and have your boss rallying the development team to make the
> first prototypes based on your designs...

That's exactly what they want me to do. Actually, they want me to design it,
then straight to production, no prototypes. Which is why I want to be sure I
actually do it right. And if doing it right includes getting some user input
on what I design before it gets built (which I think it should) rather than
just going full speed ahead and assuming I know best, then that's what I'll
do.

Most bad GUIs suffer from the same two dozen or so mistakes - you don't need
> to be a design maestro to correct or prevent them.

True, but I would think that getting user input (thru some sort of usability
testing on wireframes/mockups/paper prototypes/whatever) would (a) catch
anything I might have missed (me being fairly new to this thing) and (b)
show whether what *I think* would work actually matches user goals and
activities. (I am working in the dark to some extent—no previous user
research or even day-to-day interaction with users.)

Third: If you have trouble getting support from programmers, go to your boss
> and ask for more ammo.

Fortunately, I don't think that will be too much a problem. In fact, they
seem to welcome the fact that I will be working with them on this.

Lastly, as far as where to start... Pick small easy clear wins and repeat.
> Once you've proven you can deliver and have earned a positive reputation,
> only then look to expand.

Right on. That's solid advice that I can definitely follow.

Thanks very much,

Martin

23 May 2008 - 7:12am
james horgan
2008

No problems Martin, hope it goes well for you. I do think you have a bit of
internal marketing to do especially to shift such a large organizations
viewpoint on delivery. Identify the people who can help you make that
change and get in touch with them, there are ways to do it without ticking
off your team lead.

Scott any new idea that has support from the top people in a company tends
to get pushed forward as a result. I'm currently working on a project and if
didn't have the vocal support from Bill Gates I think it would be just seen
as another 'quack' idea rather than something that can be designed for
practical business purposes. Sometimes you've got to go direct to the
source, this is how progress is made.
All the best
James

Syndicate content Get the feed