IxD Advice for Developers

13 Jul 2006 - 10:32am
8 years ago
5 replies
444 reads
Dan Weese
2006

I enjoy reading this list although I don't have much to contribute being a developer.

I have never worked in a shop that had any Interaction Designers. Most of the time we don't even get to do any real design up front. Most of it is Extreme programming, delivering little tidbits as you go, fixing problems later rather than on the front end. We have a brief meeting with the users or decision makers, and are turned loose with a "wish list" and a deadline. I don't know of a single company in Nashville that has interaction designers.

I've been through Cooper's Interaction Design seminar, and although I try to sneak in Goal Directed Design as much as I can, I'm often fighting an uphill battle.

1. Do the members of this list have any advice for developers in my situation?

2. What are some little ways I can build more interaction design into a "develop now" mentality?

3. What are the biggest pet peeves of IxD's regarding developers that I can try to avoid?

I came into programming from a more creative field (music) about 8 years ago. I don't carry the baggage of many programmers who have been doing it since Methuselah hit puberty. I find my applications less cold and "geekish" than most of my peers. They write the code first, then make the UI conform to the code. I design how the application should look and flow, then make the code conform to the UI. I'd like to hear some tips from actual interaction designers. Am I going in the right direction?

Thanks.

Dan Weese
dweese at caelumtechnology.com

Comments

13 Jul 2006 - 12:48pm
Dan Weese
2006

Thanks for the advice!

The one thing I thought was lacking from the Cooper course I took was an
example of a spec Cooper would write. They went into some detail about what
would go into a spec, and how many pages it might be, but never gave any
examples. Many of us went away from the class feeling like it was a closely
guarded secret. As a result, I have _never_ seen a proper spec to use as a
model for projects. If I had something to work from, I would write a spec
on my own time if I had to. A proper spec not only outlines what the project
entails, but when the inevitable "feature creep" comes into play, you have
something to go by to tell you that it was never discussed in the original
design meetings, and some rework of the spec may need to be done.

Is there somewhere I can download a spec of what an IxD would document, and
maybe some lesser variations? Being able to browse through a document and
say "ahhhh....that's a good idea to document that" or "wow. I never thought
documenting tip text was important" would be invaluable. I've seen posts
where people say "go back to school and get a degree in HCI or design", but
for many people, that's simply not an option. Any help anyone can provide
with sample specs would be greatly appreciated.

Dan Weese
dweese at caelumtechnology.com

----- Original Message -----
From: "Michael Micheletti" <michael.micheletti at twistpair.com>
To: "Dan Weese" <dweese at caelumtechnology.com>; <discuss at ixda.org>
Sent: Thursday, July 13, 2006 11:33 AM
Subject: RE: [IxDA Discuss] IxD Advice for Developers

Hi Dan,

These are good questions. I've been in your shoes and know that there
are some important interaction design steps that you may not have the
time or resources to perform, like creating personas, or interviewing
and testing actual users. But I would recommend that you introduce these
two interaction design tasks that bring rapid and visible benefits to a
development team:

1. Create a detailed UI Specification document. No matter how much of a
hurry the dev team is in to get going and code, a well-written UI spec
will knock time off the development cycle. Just the process of creating
a spec with one or two others on the dev team helps everyone to align
their assumptions and expectations. The spec lets you know exactly what
you are building and when you are done building it. It also gives your
QA guys a huge leg up on creating a test plan. In your UI spec, write
down what each control does, how many states it has, what the tooltip
says, the effect it has on other controls on the screen. In a truly
rushed development project, the group process of creating the UI spec
may be almost the only interaction design you are allowed to perform, so
be detailed and make the most of it - it will prove a huge benefit.

2. Do paper prototyping. Incorporate this into your UI spec meetings.
Use hand-drawn cutouts and keep it simple. People give you funny looks
at first, and then instantly see how it helps to find conceptual errors
before you build something. In my company, people laugh and call it
"playing with paper dolls" but love to be invited to test. Our last
little project involved telephone controls and our office receptionist
just _killed_ our first design concept, but our second and third paper
prototypes were much stronger as a result. Rev the UI spec on each round
of paper prototype testing.

These two steps will open the door to interaction design for your team.
I'm looking forward to hearing recommendations from others on the list.
Hope this helps,

Michael Micheletti
Seattle, WA

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Dan
Weese
Sent: Thursday, July 13, 2006 8:32 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] IxD Advice for Developers

[Please voluntarily trim replies to include only relevant quoted
material.]

1. Do the members of this list have any advice for developers in my
situation?

2. What are some little ways I can build more interaction design into a
"develop now" mentality?

Thanks.

Dan Weese

13 Jul 2006 - 6:48pm
Robert Reimann
2003

Cooper does now offer a course on writing design specs as a follow-on to
their Practicum.

>From their website:

---

*Communicating Design Course*

This 2-day class discusses effective ways to communicate your research
findings, requirements, and design solutions. You will learn how to write
the two key design documents: the User and Domain Analysis and the Form and
Behavior Specification. You'll also learn techniques for selling your design
to stakeholders.

---
Robert.

--

Robert Reimann
President, IxDA

Manager, User Experience
Bose Corporation
Framingham, MA

On 7/13/06, Dan Weese <dweese at caelumtechnology.com> wrote:

> The one thing I thought was lacking from the Cooper course I took was an
> example of a spec Cooper would write. They went into some detail about
> what
> would go into a spec, and how many pages it might be, but never gave any
> examples. Many of us went away from the class feeling like it was a
> closely
> guarded secret. As a result, I have _never_ seen a proper spec to use as
> a
> model for projects.
>
>

14 Jul 2006 - 8:28am
Dan Weese
2006

Unfortunately, I was not able to attend the Practicum. I attended a 3 day
seminar held at the San Jose Museum. It was a great class, and made me want
to take the Practicum, but my company won't pay for it. As it was, I had to
agree to take the class in lieu of a raise that year, and I still almost had
to pay for my own hotel room. I knew this company would never let me put
these skills into practice, but I took the class for the projects I do at
home on my own time. It was worth it to me to pass up a raise to take the
class.

Dan

----- Original Message -----
From: "Robert Reimann" <rmreimann at gmail.com>
To: <discuss at ixda.org>
Sent: Thursday, July 13, 2006 6:48 PM
Subject: Re: [IxDA Discuss] IxD Advice for Developers

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Cooper does now offer a course on writing design specs as a follow-on to
> their Practicum.
>
>>From their website:
>
> ---
>
> *Communicating Design Course*
>
> This 2-day class discusses effective ways to communicate your research
> findings, requirements, and design solutions. You will learn how to write
> the two key design documents: the User and Domain Analysis and the Form
> and
> Behavior Specification. You'll also learn techniques for selling your
> design
> to stakeholders.
>
> ---
> Robert.
>
> --
>
> Robert Reimann
> President, IxDA
>
> Manager, User Experience
> Bose Corporation
> Framingham, MA
>
>
>
> On 7/13/06, Dan Weese <dweese at caelumtechnology.com> wrote:
>
>
>> The one thing I thought was lacking from the Cooper course I took was an
>> example of a spec Cooper would write. They went into some detail about
>> what
>> would go into a spec, and how many pages it might be, but never gave any
>> examples. Many of us went away from the class feeling like it was a
>> closely
>> guarded secret. As a result, I have _never_ seen a proper spec to use as
>> a
>> model for projects.
>>
>>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

14 Jul 2006 - 12:11pm
Juan Lanus
2005

Hi Dan,

First a caveat:
> I came into programming from a more creative field (music)
This is prejudice. Ask the guy who plays all nights in the night club
near your home.
In fact, both music and softdev can be creatively performed, or not,
depending on the persons and the circumstances.
Anyway, with music you can have that feeling of communication with the
public that's so special, sometimes.

Now the answers:
Can you read Spanish (no need to be a wizard)? I can send you a piece.
Anyway, lets try to describe what I think it's the proper documentation.

We build software for the users, for the people who will use it. Not
for the computer as it was the case initially, many years ago. Now the
focus in on the user.
We now also aknowledge the fact that the user is the one who knows
what's the system to do. They know *what*, and I might get to know
*how*.

To find out what is that *what* I write "use cases". The textual kind
(user readable), as opposite to diagrams (ovals with straw types
around).
I'm strongly influenced by Alistair Cockburn's book "Writing effective
Use Cases", this book can be regarded as an instructions manual.
The steps are:
1- agreeing on system scope (what's "in" and what's "out")
2- enumerating the use cases needed, working with the user
3- asigning priorities
4- writing some use cases in deep detail, at least the most critical ones
5- write code
6- maybe going back to step 2 to add newly discovered use cases

What has this to see with UI design? Well, a great deal. This is the
base of the interaction dynamics, the most important part of user
interaction.
>From the use cases the next steps are identifying the data items
mentioned in the UCs (e.g.: "... enter client data ...") and sketch
screens, forms or whatever ("Interaction Contexts", according to Larry
constantine). Read "What do users want?" from
http://www.foruse.com/articles/whatusers.htm for a short answer to
your general questions. My use cases are not "essential" as Larry's,
and I build a state transition diagram instead of his "navigation
map", but in essence there is coincidence.

What's UI for? "User Interaction" or "User interface"?
To me the first one is the most important, and includes the second
one. As of the UI design, the graphical part of it, try to apply it
the later, the better.
As Larry points in some of their articles, they noticed in practice
that in those projects where thay started to draw screens soon, it
took more time to get it right at the end.

Well enough. I'll send you an UC by email, sorry I can't put in the
web from where I'm now. It's in Spanish but the template is in
English. Write me whatever you want.
Good luck!
--
Juan Lanus
TECNOSOL
Argentina

14 Jul 2006 - 1:17pm
Dan Weese
2006

Juan,

I think you misunderstood my statement. I wasn't saying that I am more
creative than the musician in the night club. I was saying that the musician
in the night club (and myself) are probably more creatively minded than the
average programmer. When I said I came from a more creative field, I was
speaking more in comparison to developers I know who have some sort of IT
degree in programming, and tend to be more focused on the code rather than
the user. My boss for example does everything in code, even placement of
fields on the screen. He cares nothing about the UI or how much time the
development environment can save you time on with simple things like drag
and drop.

IBM did a study many years ago about how musicians make the best
programmers. That is how I got my job. My first employer in a technical
field hired me solely because I had been in music since I was 4. I had only
used a computer for about a year prior to that, just playing games and
surfing AOL. I've never even seen anything prior to Windows 95.

Dan

----- Original Message -----
From: "Juan Lanus" <juan.lanus at gmail.com>
To: "Dan Weese" <dweese at caelumtechnology.com>
Cc: <discuss at ixda.org>
Sent: Friday, July 14, 2006 12:11 PM
Subject: Re: [IxDA Discuss] IxD Advice for Developers

> Hi Dan,
>
> First a caveat:
>> I came into programming from a more creative field (music)
> This is prejudice. Ask the guy who plays all nights in the night club
> near your home.
> In fact, both music and softdev can be creatively performed, or not,
> depending on the persons and the circumstances.
> Anyway, with music you can have that feeling of communication with the
> public that's so special, sometimes.
>
> Now the answers:
> Can you read Spanish (no need to be a wizard)? I can send you a piece.
> Anyway, lets try to describe what I think it's the proper documentation.
>
> We build software for the users, for the people who will use it. Not
> for the computer as it was the case initially, many years ago. Now the
> focus in on the user.
> We now also aknowledge the fact that the user is the one who knows
> what's the system to do. They know *what*, and I might get to know
> *how*.
>
> To find out what is that *what* I write "use cases". The textual kind
> (user readable), as opposite to diagrams (ovals with straw types
> around).
> I'm strongly influenced by Alistair Cockburn's book "Writing effective
> Use Cases", this book can be regarded as an instructions manual.
> The steps are:
> 1- agreeing on system scope (what's "in" and what's "out")
> 2- enumerating the use cases needed, working with the user
> 3- asigning priorities
> 4- writing some use cases in deep detail, at least the most critical ones
> 5- write code
> 6- maybe going back to step 2 to add newly discovered use cases
>
> What has this to see with UI design? Well, a great deal. This is the
> base of the interaction dynamics, the most important part of user
> interaction.
> From the use cases the next steps are identifying the data items
> mentioned in the UCs (e.g.: "... enter client data ...") and sketch
> screens, forms or whatever ("Interaction Contexts", according to Larry
> constantine). Read "What do users want?" from
> http://www.foruse.com/articles/whatusers.htm for a short answer to
> your general questions. My use cases are not "essential" as Larry's,
> and I build a state transition diagram instead of his "navigation
> map", but in essence there is coincidence.
>
> What's UI for? "User Interaction" or "User interface"?
> To me the first one is the most important, and includes the second
> one. As of the UI design, the graphical part of it, try to apply it
> the later, the better.
> As Larry points in some of their articles, they noticed in practice
> that in those projects where thay started to draw screens soon, it
> took more time to get it right at the end.
>
> Well enough. I'll send you an UC by email, sorry I can't put in the
> web from where I'm now. It's in Spanish but the template is in
> English. Write me whatever you want.
> Good luck!
> --
> Juan Lanus
> TECNOSOL
> Argentina
>

Syndicate content Get the feed