Design Methodology for GUI development

16 Jul 2004 - 6:53am
9 years ago
30 replies
884 reads
Stephen Mallett
2004

Hi,
I am looking to use the UML( starting with Use Case diagrams) to specify &
design the layout of control systems pages for a Marine project.

If anybody has any other suggestsion for a more appropaite design methodolgy
please suggest.
thanks for any input
Stephen

Comments

16 Jul 2004 - 9:37am
Josh Seiden
2003

Well, UML isn't really a design methodology, it's a
notation system. There are some design methodologies
that make use of UML though.

Constantine and Lockwood use some UML in their Usage
Centered Design system, so you might investigate that.
<www.foruse.com>

You might also consider getting in touch with William
Hudson at Syntagm
http://www.syntagm.co.uk/design/whudson.htm. I think
that he maintains some resources about using UML with a
UCD process.

Without knowing more about your project, it's hard to
recommend a more appropriate methodology, though. But
if you're looking for UCD methods, you could start with
these:

Goal-directed design: www.cooper.com, and
http://www.amazon.com/exec/obidos/tg/detail/-/076452641
3/qid=1089988176

Contextual design: www.incent.com and
http://www.amazon.com/exec/obidos/ASIN/1558604111/qid=1
089988213

Scenario-based design:
http://www.amazon.com/exec/obidos/tg/detail/-/047107659
7/

Thanks,
JS

> Hi,
> I am looking to use the UML( starting with Use Case
diagrams)
> to specify & design the layout of control systems
pages for a
> Marine project.

16 Jul 2004 - 9:51am
Dave Malouf
2005

The other way I took this request, was for modelling methods, for as Josh
noted, UML is a modeling system and not really a design methodology.

One system that could be good is Jess James Garrett's Visual Vocabularly. It
is another modeling system for interaction design that many have had good
luck using. Here's the link: http://jjg.net/ia/visvocab/

Honestly, for myself though, I just go straight into prototyping. I think
that sketching prototypes (however you want to define sketch) is the best
way to explore/deconstruct problems and construct solutions.

What I prefer modeling for is modeling business practices and contexts that
currently exist, and less so for the business models and practices I am
trying to create. Those I keep in the prototype and I use my contextual
models around as guideposts for those prototypes.

What I find about Rational Methods (where UML) is usually deployed is that
it assumes that the problem as stated somehow has the solution in it. This
is not usually a design approach, but an engineering approach to problem
solving. Design approaches usually assume the initial problem statement is a
starting point for understanding the overal context, from which to derive a
clearer understanding of the context in which a solution will bloom out of
through iterative ideation and evaluation.

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Joshua Seiden
Sent: Friday, July 16, 2004 10:38 AM
To: 'Stephen Mallett';
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] Design Methodology for GUI development

Well, UML isn't really a design methodology, it's a notation system. There
are some design methodologies that make use of UML though.

Constantine and Lockwood use some UML in their Usage Centered Design system,
so you might investigate that.
<www.foruse.com>

You might also consider getting in touch with William Hudson at Syntagm
http://www.syntagm.co.uk/design/whudson.htm. I think that he maintains some
resources about using UML with a UCD process.

Without knowing more about your project, it's hard to recommend a more
appropriate methodology, though. But if you're looking for UCD methods, you
could start with
these:

Goal-directed design: www.cooper.com, and
http://www.amazon.com/exec/obidos/tg/detail/-/076452641
3/qid=1089988176

Contextual design: www.incent.com and
http://www.amazon.com/exec/obidos/ASIN/1558604111/qid=1
089988213

Scenario-based design:
http://www.amazon.com/exec/obidos/tg/detail/-/047107659
7/

Thanks,
JS

> Hi,
> I am looking to use the UML( starting with Use Case
diagrams)
> to specify & design the layout of control systems
pages for a
> Marine project.

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

16 Jul 2004 - 11:11am
Peter Boersma
2003

Stephen wrote:
> I am looking to use the UML( starting with Use Case diagrams) to specify &
> design the layout of control systems pages for a Marine project.
>
> If anybody has any other suggestsion for a more appropaite design
> methodolgy please suggest.

UML, and more generally, the Rational Unified Process, doesn't really
support specifying the layout of pages. Books on UML mention that "[ui
designers] read the use cases and invent a presentation"[1, p177] or refer
to "prototyping and storyboarding techniques [to] truly capture what user
friendly means"[2, p58]. In UML, high-level user interface requirements are
hidden in Boundary Classes to be detailed only after "the application
framework [..] is chosen later in development"[2, p81].

So, several companies have created additions to the RUP to deal with these
gaps.
Examples are IconProcess[3] and Satama Unified Process[4]. IconMedialab
reworked the Business Modeling workflow into the Business Strategy workflow
and added a UserExperience workflow. Satama placed the Discovery Phase in
front of other phases and added the User Exploration workflow.

In my current company (I used to work for Satama) I am doing this as well,
under the working title "STUX" (STandards for User eXperience, you can see
why we added the "T" ;-)). We've defined a User Experience workflow with
detailed activities for the roles of System Analysts, Information
Architects, Interaction Designers, Usability & Accessibility Testers,
Content Designers, and Visual and Information Designers. It's still under
construction (we're currently designing the overview poster for internal
use) and might never really become public-domain.

Most of these additions center around methods for capturing user
requirements, performing interaction design and specifying layout of
screens, plus their integration with the rest of the methodology.

JJG's Visual Vocabulary[5] is a tool to help create standardized screenflows
but not layout, as Jesse himself explains: "As with navigation, details of
interface should not appear in the diagram -- if you find yourself drawing
buttons and fields, you're probably loading the diagram down with excess
detail. "

In my work as an information architect I've also found that it is relatively
easy to work with a limited set of elements to specify screenflows, but it's
harder to do the same for wirefames that begin to specify layout. In my
current job we have created a set of symbols and an associated tool that
generates good-looking, standardized screenflows[6] but for each project we
have to tweak the set of wireframe elements, although that is slowly
consolidating too.

I'd love to hear what methodologies other use...

Peter

[1] from "Writing Effective Use Cases", Alistair Cockburn, Addison Wesley,
2001
[2] from "Visual Modeling with Rational Rose 2002 and UML", Terry Quatrani,
Addison Wesley, 2003
[3] IconProcess, www.iconprocess.com
[4] Satama Unified Process, www.satama.com/sup.jsp
[6] for the J-Flow, see: http://www.iasummit.org/confdescrip.htm#go35 and
http://www.xs4all.nl/~nieuwnet/iasummit/
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

16 Jul 2004 - 11:14am
Peter Boersma
2003

David wrote:
> Honestly, for myself though, I just go straight into prototyping. I think
> that sketching prototypes (however you want to define sketch) is the best
> way to explore/deconstruct problems and construct solutions.

But what if, after the sketching, you want to formally specify a design?
What notational systems do you use?

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

16 Jul 2004 - 12:51pm
Dave Malouf
2005

If you mean to pass-off to developers, I take my prototype and anotate
directly on it.

One of the things I didn't say is that the prototypes get higher and higher
fidelity during the iterative process.

-- dave

-----Original Message-----
From: Peter Boersma [mailto:peter.boersma at ezgov.com]
Sent: Friday, July 16, 2004 12:15 PM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Cc: David Heller
Subject: RE: [ID Discuss] Design Methodology for GUI development

David wrote:
> Honestly, for myself though, I just go straight into prototyping. I
> think that sketching prototypes (however you want to define sketch) is
> the best way to explore/deconstruct problems and construct solutions.

But what if, after the sketching, you want to formally specify a design?
What notational systems do you use?

Peter
--
Peter Boersma - Senior Information Architect - EzGov Rijnsburgstraat 11 -
1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

16 Jul 2004 - 4:06pm
Christian Simon
2003

> on 7/16/04 12:02, wrote:
> If anybody has any other suggestsion for a more appropaite design methodolgy
> please suggest.

Wouldn't there be time consuming implications to bringing a full methodology
to management? I imagine the human factors people becoming annoyed at having
to manage for a new series of deliverables. Maybe this is just speaking from
ignorance. Another solution could be to cobble together a series of
patterns. Get project owners onboard and coax them on the ball for
requirements when they see a Frankenstein UI comes to their desk. Eeek!

Xtian

////////////////////christiansimon at pacbell.net\\\\\\\\\\\\\\\\\\\\\\\

17 Jul 2004 - 12:40am
pabini
2004

Hello All

Like Dave, I often go straight to sketching prototypes of user interfaces,
both during conceptual modeling and design.

However, performing an objects/actions analysis during conceptual modeling,
as Jeff Johnson describes in his book, "GUI Bloopers," is an excellent way
of determining the similarities and relationships between objects that your
product presents to users and a clear organizational model for those
objects. It's really helpful in bringing consistency and order to user
interface designs.

When specifying a user interface, I write detailed specifications that
follow very consistent patterns in presenting information, which I think are
much clearer than any modeling language or flowchart I've ever seen. Since
they're written in clear language, there's no learning curve on the part of
those using the specs, who might not know a particular notation system.

For the complex user interfaces I've specified, annotations on a prototype
wouldn't even begin to cut it. The specs for a particular product release
might be 400 or 500 pages in length, including all of the screen images.

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

----- Original Message -----
From: "David Heller" <dave at interactiondesigners.com>
To: <discuss-interactiondesigners.com at lists.interactiondesigners.com>
Sent: Friday, July 16, 2004 7:51 AM
Subject: RE: [ID Discuss] Design Methodology for GUI development

> The other way I took this request, was for modelling methods, for as Josh
> noted, UML is a modeling system and not really a design methodology.
>
> One system that could be good is Jess James Garrett's Visual Vocabularly.
It
> is another modeling system for interaction design that many have had good
> luck using. Here's the link: http://jjg.net/ia/visvocab/
>
> Honestly, for myself though, I just go straight into prototyping. I think
> that sketching prototypes (however you want to define sketch) is the best
> way to explore/deconstruct problems and construct solutions.
>
> What I prefer modeling for is modeling business practices and contexts
that
> currently exist, and less so for the business models and practices I am
> trying to create. Those I keep in the prototype and I use my contextual
> models around as guideposts for those prototypes.
>
> What I find about Rational Methods (where UML) is usually deployed is that
> it assumes that the problem as stated somehow has the solution in it. This
> is not usually a design approach, but an engineering approach to problem
> solving. Design approaches usually assume the initial problem statement is
a
> starting point for understanding the overal context, from which to derive
a
> clearer understanding of the context in which a solution will bloom out of
> through iterative ideation and evaluation.
>
> -- dave

17 Jul 2004 - 9:15am
Dave Malouf
2005

Wow, great discussion.

Pabini's last post hit a nerve in me and when I started replying I realized
that there are so many issues we aren't considering.

1. design vs. communicating that design
2. in-house vs. out-of-house
3. project properties (complexity, timeline, team makeup)

Then through the discussion it also become clear to me that another issue is
"what is a prototype?" I'm sure we can all read about it in the dictionary,
but when it comes down to it a prototype is just a temporary, incomplete
representation of a future more completed design. This can be a pencil
sketch or an elaborate interactive flash piece, and everything in between.

Couple of other thoughts:
There was a thread on SIGIA-L probably years ago about the power of
employing hand to paper when doing design. That drawing take the mind and
forces it to use both sides, where other processes might leave the person
with just one. By combining the physical motion with the visual
representation that merger takes place. This is why I go directly to
sketches (usually on whiteboard for me).

I think that design is a very complex activity and one that in the end is
going to balance the personal with the team with the context. Design
communication is about team management and needs to fit that explicit
context which may have the added component of in-house vs. out-of-house. The
latter requires a level of detail that the former may not depending on where
you are. "detail" isn't meant to mean that you can leave stuff out, but well
that it doesn't have to look "pretty" b/c you aren't "selling" the the
documentation to anyone. There is no "leave-behind".

Last point on this thread:
One of the points I tried to make in my earlier post was less about the
prototyping then about design process and where we can achieve more as
designers vs. engineers or business analysts. It is important as designers
for us to bring in what we do best; that is, we deconstruct. Engineers look
at a problem statement and see a solution in those same words. i.e. "I can't
do this fast enough." The solution is obvious to the engineer, "Make the
system faster (perform better)." The business analyst takes a little step
back and says, well maybe it is a process issue, "Reduce the amount that
needs to get done.", the designer comes in and says, "Let me see what you
are doing. ... Observes the environment and says, "Time will be perceived to
be faster if the user is given a certain amount of feedback and if music is
playing in the background while waiting is occuring."

While the 1st two approaches were quick up-front their "solutions" didin't
really address the real problem, b/c they never took the time to get to the
real problem, deconstruct it into its parts and re-evaluate it. The
designer's method took more time, but the overall solution (in this case)
cost so much less in resources to implement. Now that being said, not all
design solutions are cheaper, but the process more often than not affords
the possibility because we don't accept the initial problem statement as the
basis for building that solution.

The other part of the design process is one that starts without judgement
through iterative ideation and then moves through evaluation towards
decision. While "without judgement" is not a relative reality b/c we are
always doing our own self-judgement, there is still more room to break free
and innovate in the design model where evaluation is suspended to specific
intervals in the process.

Now taking this back to the original poster and my point about going
straight to prototype. My assumption from the posting was that he/she was
using UML as a design method/process. And I was suggesting that "modeling"
in UML is used in the RP methodology and that methodology assumes that the
problem being solved already has an answer. This was the first piece I was
trying to break away from. Maybe you can use UML as a notation method to
derive iteration, but I have found that UML is an after the fact process,
that defines a solution and does not design the solution.

-- dave

David Heller
dave (at) interactiondesigners (dot) com
http://interactiondesigners.com/
http://htmhell.com/

AIM: bolinhanyc // Y!: dave_ux // MSN: hippiefunk at hotmail.com

17 Jul 2004 - 1:43pm
Stephen Mallett
2004

I am glad I started this off I have learnt some good stuff so far.

I have been prototyping a lot but I need a formal way to write/draw what I
want each part of the UI to do/present. I am having to interface with our
process control code ( moves ship about various bits of water) which
requires that I define my end of the interfaces. As soon as we show our
customer any prototype screens we get stuck with the details like pipe
alignments, pump colours etc.. & often miss the point of the page so I am
looking for an alternative presentation of the information

I now have loads of reference to look at.
Thanks for all your info- feel free to continue - I am enjoying I hope to
rest of the particapaents are.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Sent: 17/07/04 10:15
Subject: RE: [ID Discuss] Design Methodology for GUI development

Wow, great discussion.

Pabini's last post hit a nerve in me and when I started replying I
realized
that there are so many issues we aren't considering.

1. design vs. communicating that design
2. in-house vs. out-of-house
3. project properties (complexity, timeline, team makeup)

Then through the discussion it also become clear to me that another
issue is
"what is a prototype?" I'm sure we can all read about it in the
dictionary,
but when it comes down to it a prototype is just a temporary, incomplete
representation of a future more completed design. This can be a pencil
sketch or an elaborate interactive flash piece, and everything in
between.

Couple of other thoughts:
There was a thread on SIGIA-L probably years ago about the power of
employing hand to paper when doing design. That drawing take the mind
and
forces it to use both sides, where other processes might leave the
person
with just one. By combining the physical motion with the visual
representation that merger takes place. This is why I go directly to
sketches (usually on whiteboard for me).

I think that design is a very complex activity and one that in the end
is
going to balance the personal with the team with the context. Design
communication is about team management and needs to fit that explicit
context which may have the added component of in-house vs. out-of-house.
The
latter requires a level of detail that the former may not depending on
where
you are. "detail" isn't meant to mean that you can leave stuff out, but
well
that it doesn't have to look "pretty" b/c you aren't "selling" the the
documentation to anyone. There is no "leave-behind".

Last point on this thread:
One of the points I tried to make in my earlier post was less about the
prototyping then about design process and where we can achieve more as
designers vs. engineers or business analysts. It is important as
designers
for us to bring in what we do best; that is, we deconstruct. Engineers
look
at a problem statement and see a solution in those same words. i.e. "I
can't
do this fast enough." The solution is obvious to the engineer, "Make the
system faster (perform better)." The business analyst takes a little
step
back and says, well maybe it is a process issue, "Reduce the amount that
needs to get done.", the designer comes in and says, "Let me see what
you
are doing. ... Observes the environment and says, "Time will be
perceived to
be faster if the user is given a certain amount of feedback and if music
is
playing in the background while waiting is occuring."

While the 1st two approaches were quick up-front their "solutions"
didin't
really address the real problem, b/c they never took the time to get to
the
real problem, deconstruct it into its parts and re-evaluate it. The
designer's method took more time, but the overall solution (in this
case)
cost so much less in resources to implement. Now that being said, not
all
design solutions are cheaper, but the process more often than not
affords
the possibility because we don't accept the initial problem statement as
the
basis for building that solution.

The other part of the design process is one that starts without
judgement
through iterative ideation and then moves through evaluation towards
decision. While "without judgement" is not a relative reality b/c we are
always doing our own self-judgement, there is still more room to break
free
and innovate in the design model where evaluation is suspended to
specific
intervals in the process.

Now taking this back to the original poster and my point about going
straight to prototype. My assumption from the posting was that he/she
was
using UML as a design method/process. And I was suggesting that
"modeling"
in UML is used in the RP methodology and that methodology assumes that
the
problem being solved already has an answer. This was the first piece I
was
trying to break away from. Maybe you can use UML as a notation method to
derive iteration, but I have found that UML is an after the fact
process,
that defines a solution and does not design the solution.

-- dave

David Heller
dave (at) interactiondesigners (dot) com
http://interactiondesigners.com/
http://htmhell.com/

AIM: bolinhanyc // Y!: dave_ux // MSN: hippiefunk at hotmail.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

18 Jul 2004 - 8:56am
pabini
2004

Hi Dave

Now you've got me wondering what hit a nerve. :-) Which nerve? ;-) You've
raised some interesting issues.

My personal design process is the same whether I'm working in house or as a
consultant, but of course, the overall design process can vary depending on
the culture and process at a particular company--not to mention
time-to-market constraints.

The issue of "design vs. communicating that design" is a very interesting
one. I'd been doing the latter in a particular way for many years--writing
those specs that I mentioned--but getting involved in Web design has
influenced what work products I produce somewhat. Wireframes have become
very popular and prototyping now typically has much lower fidelity than it
once did, which I personally think is great. So our interaction design
process is evolving. I still write those specs though, because they're so
effective. Creating a high-quality design document really gets the attention
of the engineers and other members of a product development team, which I
don't think quick-and-dirty approaches can do as effectively. The refinement
and detail demonstrate that a lot of thought went into the design and that I
understand what information the engineers need. So I don't really agree with
the statement that "it doesn't have to be pretty." In fact, we are selling
the designs we create. If design documentation can effectively do that, it's
worth every bit of effort involved in creating it. Of course, it's a lot
easier to make text look pretty. Nothing to it, in fact, if one has a good
template.

I wonder whether if people who are involved primarily in Web design--and
creating wireframes--think of writing long specs, they think of a protracted
process. I actually think creating screen images and writing specs is a
quicker process than some. I can design, create screen images, and write the
kind of spec I described in a couple of months. Writing is quicker than
high-quality drawing. :-) I've seen some gorgeous wireframes though.

I really liked your comment on the integrative aspect of drawing a design. I
think you've hit on a truth there. Drawing does pull left- and right-brain
thinking together. I also think that people in whom both hemispheres of the
brain are equally developed make the best interaction designers. We need to
be very analytical to design software--that deconstruction that you were
talking about and construction, too--but we also need to be empathic and
sensitive to the needs of people.

Your last, long point about the design process was very well stated and held
a lot of truth.

Pabini

David Heller wrote: Wow, great discussion.
>
> Pabini's last post hit a nerve in me and when I started replying I
realized
> that there are so many issues we aren't considering.
>
> 1. design vs. communicating that design
> 2. in-house vs. out-of-house
> 3. project properties (complexity, timeline, team makeup)
>
> Then through the discussion it also become clear to me that another issue
is
> "what is a prototype?" I'm sure we can all read about it in the
dictionary,
> but when it comes down to it a prototype is just a temporary, incomplete
> representation of a future more completed design. This can be a pencil
> sketch or an elaborate interactive flash piece, and everything in between.
>
> Couple of other thoughts:
> There was a thread on SIGIA-L probably years ago about the power of
> employing hand to paper when doing design. That drawing take the mind and
> forces it to use both sides, where other processes might leave the person
> with just one. By combining the physical motion with the visual
> representation that merger takes place. This is why I go directly to
> sketches (usually on whiteboard for me).
>
> I think that design is a very complex activity and one that in the end is
> going to balance the personal with the team with the context. Design
> communication is about team management and needs to fit that explicit
> context which may have the added component of in-house vs. out-of-house.
The
> latter requires a level of detail that the former may not depending on
where
> you are. "detail" isn't meant to mean that you can leave stuff out, but
well
> that it doesn't have to look "pretty" b/c you aren't "selling" the the
> documentation to anyone. There is no "leave-behind".
>
> Last point on this thread:
> One of the points I tried to make in my earlier post was less about the
> prototyping then about design process and where we can achieve more as
> designers vs. engineers or business analysts. It is important as designers
> for us to bring in what we do best; that is, we deconstruct. Engineers
look
> at a problem statement and see a solution in those same words. i.e. "I
can't
> do this fast enough." The solution is obvious to the engineer, "Make the
> system faster (perform better)." The business analyst takes a little step
> back and says, well maybe it is a process issue, "Reduce the amount that
> needs to get done.", the designer comes in and says, "Let me see what you
> are doing. ... Observes the environment and says, "Time will be perceived
to
> be faster if the user is given a certain amount of feedback and if music
is
> playing in the background while waiting is occuring."
>
> While the 1st two approaches were quick up-front their "solutions" didin't
> really address the real problem, b/c they never took the time to get to
the
> real problem, deconstruct it into its parts and re-evaluate it. The
> designer's method took more time, but the overall solution (in this case)
> cost so much less in resources to implement. Now that being said, not all
> design solutions are cheaper, but the process more often than not affords
> the possibility because we don't accept the initial problem statement as
the
> basis for building that solution.
>
> The other part of the design process is one that starts without judgement
> through iterative ideation and then moves through evaluation towards
> decision. While "without judgement" is not a relative reality b/c we are
> always doing our own self-judgement, there is still more room to break
free
> and innovate in the design model where evaluation is suspended to specific
> intervals in the process.
>
> Now taking this back to the original poster and my point about going
> straight to prototype. My assumption from the posting was that he/she was
> using UML as a design method/process. And I was suggesting that "modeling"
> in UML is used in the RP methodology and that methodology assumes that the
> problem being solved already has an answer. This was the first piece I was
> trying to break away from. Maybe you can use UML as a notation method to
> derive iteration, but I have found that UML is an after the fact process,
> that defines a solution and does not design the solution.
>
> -- dave
>
> David Heller
> dave (at) interactiondesigners (dot) com
> http://interactiondesigners.com/
> http://htmhell.com/
>
> AIM: bolinhanyc // Y!: dave_ux // MSN: hippiefunk at hotmail.com
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

19 Jul 2004 - 8:34am
Gerard Torenvliet
2004

David Heller wrote (my apologies for the long quote; it's important):

> One of the points I tried to make in my earlier post was less
> about the prototyping then about design process and where
> we can achieve more as designers vs. engineers or business
> analysts. It is important as designers for us to bring in what
> we do best; that is, we deconstruct. Engineers look at a
> problem statement and see a solution in those same words.
> i.e. "I can't do this fast enough." The solution is obvious
>to the engineer, "Make the system faster (perform better)."
> The business analyst takes a little step back and says, well
> maybe it is a process issue, "Reduce the amount that needs
> to get done.", the designer comes in and says, "Let me see
> what you are doing. ... Observes the environment and says,
> "Time will be perceived to be faster if the user is given a
> certain amount of feedback and if music is playing in the
> background while waiting is occuring."

> While the 1st two approaches were quick up-front their "
> solutions" didin't really address the real problem, b/c they
> never took the time to get to the real problem, deconstruct
> it into its parts and re-evaluate it. The designer's method took
> more time, but the overall solution (in this case) cost so much
> less in resources to implement. Now that being said, not all
> design solutions are cheaper, but the process more often than
> not affords the possibility because we don't accept the initial
> problem statement as the basis for building that solution.

I agree with you fully that the hallmark of good human-centred design is to look beyond the user's requirements, and to treat them as symptoms, so that we can get to the real requirement. I disagree that only designers do this, and that this is not part of the engineering toolkit. You're making a false distinction between the two.

In the case that you state, the designer is using (consciously or not) systems engineering principles to examine the entire system of performance (software ressponsiveness + human perception of that responsiveness). A systems engineer (or designer, or whatever) might even find out that process itself is not even needed, bringing in the business analyst - process redesign part to come up with a better process.

Like it or not, design is engineering, engineering is design, and both are more than just that.

Where I think the distinction that you make becomes true is in the way various engineers exert their influence. Software engineers see the world as an operating system; mechanical engineers see the world as an internal combustion engine; human factors engineers see the world as a perception-action system; and systems engineers see the world as a socio-technical system. They each have tools, and so their solutions use those tools. Experience shows that no one perspective (even the design perspective) works in isolation.

What we need are more people who can integrate concepts from a broad variety of disciplines - engineering, social sciences, art, psychology, and whatever - and who are willing to admit their ignorance in any disciplines they don't know and so call in other expertise. We need generalists who can corral ideas from specialists, merge them into an overall vision of the design, and then manage that design until it is delivered and then out into the field.

I don't think we disagree on the goal. I'm just concerned that engineers of all stripes are people that we need to keep on board (perhaps with a goal to change their way of thinking about problem solving) if we are going to make this happen. Engineers do not all suffer from the tunnel-vision of not being able to read beyond the requirement. They just need the assistance of good people to help them do so; the good people (read design professionals, or systems engineers, or human factors engineers, or whatever) need specialist engineers in order to make their vision come to be.

But then again, I have a bias - 7 years of engineering education and eight years of practice. :-)

Regards,
-Gerard

:: Gerard Torenvliet / gerard.torenvliet at cmcelectronics.ca
:: Human Factors Engineering Design Specialist
:: CMC Electronics Inc.
::
:: Ph - 613 592 7400 x 2613
:: Fx - 613 592 7432
::
:: 415 Legget Drive, P.O. Box 13330
:: Ottawa, Ontario, CANADA, K2K 2B2
:: http://www.cmcelectronics.ca

19 Jul 2004 - 9:19am
Dave Malouf
2005

Gerard said, "engineering is design; design is engineering"

I have to say that you might make that truism, but I do not have
observational experience that shows me that, at least in the software world.

My observation of various types of software engineers is that they do what
they are told to do. This is probably based on a specific type of culture,
but I have seen it in many environments and attempts at bringing a "design"
methodology to software programming has usually failed.

Why?
Timelines are too short for the most part so "iteration" is not a luxury
that they have had for the last few decades.
Business people have been "too educated" and thus "know what is best" and
don't give room to engineers to think outside the requirements.

But my main point was around process and I'm not sure I have ever seen in
any engineering circles anything that approximated the type of research and
modeling that goes on with designers. I have seen it in industrial design,
interaction design, information architecture, architecture, etc. But not in
mechanical engineering, civil engineering and definitely not in EECS.

The truism you were trying to exert just doesn't wash in the observed data
from my pretty broad experience.

Historically, design has had a very different set of practices, methods, and
theories than engineering has. Engineering for the most part is devode of
the emotional and aesthetic and thus disconnected from the humaness of the
constructs. Design is all about the human being. This intrisically makes
them separate. I also think that the 3 examples I gave about an engineering
approach, business analyst approach and design approach to a problem fit my
general world experience, and while is yet another truism, I find it much
more believable based on that experience than the one that was presented in
opposition. But that being said, maybe it just doesn't matter that there is
any difference at all. What I was trying to say is that RUP doesn't allow
for the types of design processes that I was attempting to explore whether
comparative or not b/c they assume the requirement as given is the
requirement to be implemented. Maybe engineers do this level of
deconstruction, maybe they don't, but we do and this is what is most
important.

Personally, I do think that (software) engineers don't get it and they
desparately need our help. ;)

-- dave

19 Jul 2004 - 10:12am
Gerard Torenvliet
2004

Dave,

I think you are generalizing from software engineers (a specific specialty) to the whole domain of engineering. My point was that there are disciplines of engineering that deal with and have processes for exactly the type of methodologies that you are calling for.

Systems design engineering has them; Human factors engineering has them. Contextual Design (Beyer & Holtzblatt) is probably the most relevant to general product design. The military also has various standards dictating human-centred design processes. There's also Carroll's "Scenario-based Design". I don't know much about RUP, but this book might help anyone who is interested.

http://www.pearson.ch/pageid/34/artikel/65789AW/Addison-Wesley/0201657899/ObjectModelingandUser.aspx

(I don't have much faith in RUP, but that is just a naive impression. Contextual design (CD) is amazing; whereever I've been able to apply the techniques, I've been astonished.)

I'm not sure that it is just software engineers that need our help. Product management needs our help; they need to see that there is something beyond a three-month product development cycle. Software engineers do as well as they can within their constraints; if we were to help them blow away their constraints, I do wonder what would happen.

Your last statement to me makes the point: "Maybe engineers do this level of deconstruction, maybe they don't, but we do and this is what is most important." I think that what we both do is of utmost importance. We all need to leverage each other's best techniques and best skills. If engineering has solved some substantive problems, let's look to them. More importantly, if we are ever to get respect from engineering in terms of putting a methodology in place, we need to give them as much respect as we hope to get. Once we get that cycle of respect, we can begin building a truly co-operative, multi-disciplinary design culture. I think that is everyone's vision here.

-Gerard

P.S. I believe my truism still stands. Most major schools teach engineering as a design practice. I need to understand your definition of design before I can reject the idea that engineering and interaction design are aiming at the same goals. We don't need to deal with this point to move ahead right now; it's the tricky bit about semantics that is so tough to solve.

:: Gerard Torenvliet / gerard.torenvliet at cmcelectronics.ca
:: Human Factors Engineering Design Specialist
:: CMC Electronics Inc.
::
:: Ph - 613 592 7400 x 2613
:: Fx - 613 592 7432
::
:: 415 Legget Drive, P.O. Box 13330
:: Ottawa, Ontario, CANADA, K2K 2B2
:: http://www.cmcelectronics.ca

19 Jul 2004 - 10:16am
Peter Boersma
2003

David wrote:
> [...] What I was trying to say is that RUP doesn't allow
> for the types of design processes that I was attempting to explore whether
> comparative or not b/c they assume the requirement as given is the
> requirement to be implemented.

In defense of RUP I must say that, although RUP is very
requirements-focussed, the methodolgy does allow for iterative design,
starting with high-level requirements ("vision", cf. sketching), then
focussing on critical elements of the solution ("high-risk use-cases", cf.
screenflows/wireframes) and finally on screen details ("business rules", cf.
detailed interaction design).

One of my current issues with RUP is that the selection of which use-cases
are the high-risk ones is based purely on "archictural complexity", i.e.
software complexity. I am fighting for a second scale for high risk-ness
that is bases on user experience complexity or impact. Whether the 2 scales
can be combined into 1 or not, and what their relative weights would be, has
to be determined based on experience, I am afraid.

Has anyone else developed a scale for user experience complexity/impact of
use cases? If so, what is the format? Is it a checklist, a set of
guidelines, patterns?

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

19 Jul 2004 - 10:59am
Peter Boersma
2003

Pabini Gabriel-Petit wrote:
> I wonder whether if people who are involved primarily in Web design--and
> creating wireframes--think of writing long specs, they think of a
protracted
> process. I actually think creating screen images and writing specs is a
> quicker process than some. I can design, create screen images, and write
the
> kind of spec I described in a couple of months. Writing is quicker than
> high-quality drawing. :-) I've seen some gorgeous wireframes though.

Writing long specs is what I try to avoid at all costs.

Putting the bare minimum of specifications in the wireframes (with some room
for notes), and deferring details of the working of global elements to
seperate lean & mean documents is my preferred way to go.

I work with project teams of 10 to 30 people, and most of them are
specialists who focus on a small piece of a solution at a time. If *all* of
them have to work through *all* of the documentation *all* the time, we have
a problem :-) If one developer focusses on building the locig behind, say,
the main navigation, then he/she gets to read the specification document on
the main navigation. If another developer needs to focus on the behaviour of
next/previous buttons of our web application, then he/she gets to read the
specification of that behaviour. If an interaction designer needs to specify
the design of a set of screens, he/she gets to read the business
requirements and high-level interaction design guidelines.
Of course, these seperate documents do get reviewed by a larger group (not
just me and the developer) in peer reviews and team reviews, before they get
sent out to the developer. Also, all of these requirements documents
(because that's what they are considered to be in the RUP approach) are
managed and version-controlled by our requirements managers. I think they
call them "supplementary specs" ;-)

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

19 Jul 2004 - 11:05am
Peter Boersma
2003

Christian wrote:
> Wouldn't there be time consuming implications to bringing a full
methodology
> to management? I imagine the human factors people becoming annoyed at
having
> to manage for a new series of deliverables. Maybe this is just speaking
from
> ignorance.

I wouldn't call it ignorance: It's a matter of accountability, measurement,
return on investment, whatever you want to call it. If you want to know what
your results are (and not everybody wants to, has to, or is ready for this)
you need to specify what you do, how you measure if you do it right or not,
measure, and act upon the results.

Specifying your deliverables (which is part of what introducing a
methodology does) is just the first step!

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

19 Jul 2004 - 11:59am
Robert Reimann
2003

Pabini Gabriel-Petit wrote:

> However, performing an objects/actions analysis during conceptual
modeling, as Jeff Johnson describes in
> his book, "GUI Bloopers," is an excellent way of determining the
similarities and relationships between
> objects that your product presents to users and a clear organizational
model for those objects. It's really
> helpful in bringing consistency and order to user interface designs.

I completely agree that analyzing object and actions is
an important step in the conceptual modeling phase of a
design. However, the steps that lead up to it are
equally critical:

1) Understanding who the users are (via market and ethnographic research)
2) Understanding their goals/motivations in the context of the product
(via personas and other user modeling/analysis)
3) Identifying user needs from goals (via user models and context scenarios)
4) Translating needs into objects and actions (via scenarios and task/flow
analysis)

Note that the scenarios mentioned above aren't quite the same as
use cases in that they focus on the qualitative user experience
(meeting goals, eliminating extraneous tasks) as well as data flow
between system and human.

If you are able to follow these steps, you'll find that your
objects and actions naturally follow from the behaviors, goals
and needs of users as explored in your scenarios, which
allows you to see even more clearly the relationships and
task flows between object and actions you've identified.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Pabini Gabriel-Petit
Sent: Saturday, July 17, 2004 1:40 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: Re: [ID Discuss] Design Methodology for GUI development

Hello All

Like Dave, I often go straight to sketching prototypes of user interfaces,
both during conceptual modeling and design.

However, performing an objects/actions analysis during conceptual modeling,
as Jeff Johnson describes in his book, "GUI Bloopers," is an excellent way
of determining the similarities and relationships between objects that your
product presents to users and a clear organizational model for those
objects. It's really helpful in bringing consistency and order to user
interface designs.

When specifying a user interface, I write detailed specifications that
follow very consistent patterns in presenting information, which I think are
much clearer than any modeling language or flowchart I've ever seen. Since
they're written in clear language, there's no learning curve on the part of
those using the specs, who might not know a particular notation system.

For the complex user interfaces I've specified, annotations on a prototype
wouldn't even begin to cut it. The specs for a particular product release
might be 400 or 500 pages in length, including all of the screen images.

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

----- Original Message -----
From: "David Heller" <dave at interactiondesigners.com>
To: <discuss-interactiondesigners.com at lists.interactiondesigners.com>
Sent: Friday, July 16, 2004 7:51 AM
Subject: RE: [ID Discuss] Design Methodology for GUI development

> The other way I took this request, was for modelling methods, for as
> Josh noted, UML is a modeling system and not really a design
> methodology.
>
> One system that could be good is Jess James Garrett's Visual
> Vocabularly.
It
> is another modeling system for interaction design that many have had
> good luck using. Here's the link: http://jjg.net/ia/visvocab/
>
> Honestly, for myself though, I just go straight into prototyping. I
> think that sketching prototypes (however you want to define sketch) is
> the best way to explore/deconstruct problems and construct solutions.
>
> What I prefer modeling for is modeling business practices and contexts
that
> currently exist, and less so for the business models and practices I
> am trying to create. Those I keep in the prototype and I use my
> contextual models around as guideposts for those prototypes.
>
> What I find about Rational Methods (where UML) is usually deployed is
> that it assumes that the problem as stated somehow has the solution in
> it. This is not usually a design approach, but an engineering approach
> to problem solving. Design approaches usually assume the initial
> problem statement is
a
> starting point for understanding the overal context, from which to
> derive
a
> clearer understanding of the context in which a solution will bloom
> out of through iterative ideation and evaluation.
>
> -- dave

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

19 Jul 2004 - 3:56pm
Elizabeth Buie
2004

Dave Heller writes:

<<My observation of various types of software engineers is that they do
what
they are told to do. This is probably based on a specific type of culture,
but I have seen it in many environments...>>

My experience is the opposite. I've been in basically one type of culture
(government contracting) during my 29 years in the software industry, but
have worked on various projects and with various groups over the years. I
have found that software engineers have different levels of skills and
sensitivities/sensibilities when it comes to interaction design, but most
of them do want to contribute to the design. If an SWE has no skill in
interaction design I'd rather they didn't try to get in on the act, but
I'd far rather collaborate with an SWE who "gets it" and can work *with*
me, than throw my designs over the transom to one who just wants to "do
what they're told".

Elizabeth

--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland
301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

19 Jul 2004 - 4:07pm
Dave Malouf
2005

Hi elizabeth, I wasn't saying what I preferred, I was describing what I have
found to be the culture of the institutions where I have worked for the last
10 years from in-house software firm, to client service agencies of many
different types.

While I do find that there are engineers who want to contribute, I find that
they just can't because their perspective is very much locked into the
requirement itself, as I was originally explaining.

What I would want is that the whole team is as engaged in the
ideation/evaluation process as I am as a designer.

- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Elizabeth Buie
Sent: Monday, July 19, 2004 4:56 PM
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] Design Methodology for GUI development

Dave Heller writes:

<<My observation of various types of software engineers is that they do what
they are told to do. This is probably based on a specific type of culture,
but I have seen it in many environments...>>

My experience is the opposite. I've been in basically one type of culture
(government contracting) during my 29 years in the software industry, but
have worked on various projects and with various groups over the years. I
have found that software engineers have different levels of skills and
sensitivities/sensibilities when it comes to interaction design, but most of
them do want to contribute to the design. If an SWE has no skill in
interaction design I'd rather they didn't try to get in on the act, but I'd
far rather collaborate with an SWE who "gets it" and can work *with* me,
than throw my designs over the transom to one who just wants to "do what
they're told".

Elizabeth

--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland
301.921.3326

----------------------------------------------------------------------------
------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------
------------

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

20 Jul 2004 - 5:41am
pabini
2004

Peter Boersma wrote: Writing long specs is what I try to avoid at all costs.
>
> Putting the bare minimum of specifications in the wireframes (with some
room
> for notes), and deferring details of the working of global elements to
> seperate lean & mean documents is my preferred way to go.

***[PGP] I can see from your title that you work on Web sites. Web
sites--because of the limits of the technology behind them--are typically
very simple stuff from an interaction design viewpoint. It's mainly
navigation. I predominantly work on very complex desktop software and Web
applications implemented as binary code for specific platforms. If I didn't
write detailed specs, I'd basically be telling the engineers to implement
interactions in any way they liked. When I design Web applications
implemented in HTML, I still write specs, but obviously they're
comparatively brief. I don't generally work on Web sites, but in that case,
annotated wireframes might be sufficient.

> I work with project teams of 10 to 30 people, and most of them are
> specialists who focus on a small piece of a solution at a time.

***I've worked with much larger and also smaller teams of engineers.

If *all* of
> them have to work through *all* of the documentation *all* the time, we
have
> a problem :-)

***They don't. You must be assuming some pretty poorly organized
documentation. The engineering manager assigns responsibility for
implementing specific functionality to specific engineers, who go to the
table of contents, find the sections about that part of the product, and
implement it to spec. The product has better consistency throughout, because
everything is specified in detail.

If one developer focusses on building the locig behind, say,
> the main navigation, then he/she gets to read the specification document
on
> the main navigation. If another developer needs to focus on the behaviour
of
> next/previous buttons of our web application, then he/she gets to read the
> specification of that behaviour. If an interaction designer needs to
specify
> the design of a set of screens, he/she gets to read the business
> requirements and high-level interaction design guidelines.

***Nothing different here.

> Of course, these seperate documents do get reviewed by a larger group (not
> just me and the developer) in peer reviews and team reviews, before they
get
> sent out to the developer.

***Yes, but in my world, the lead engineers are in those meetings, too. In
fact, their participation is essential.

Also, all of these requirements documents
> (because that's what they are considered to be in the RUP approach) are
> managed and version-controlled by our requirements managers. I think they
> call them "supplementary specs" ;-)

***In my universe, there are high-level marketing requirements documents
that I work from, but that's about it. Sometimes there are systems analyses
of backend stuff. Generally, I specify everything, then the engineers
implement the product to my specs.

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

20 Jul 2004 - 6:10am
pabini
2004

Robert Reimann wrote:

> I completely agree that analyzing object and actions is
> an important step in the conceptual modeling phase of a
> design. However, the steps that lead up to it are
> equally critical:
>
> 1) Understanding who the users are (via market and ethnographic research)
> 2) Understanding their goals/motivations in the context of the product
> (via personas and other user modeling/analysis)
> 3) Identifying user needs from goals (via user models and context
scenarios)
> 4) Translating needs into objects and actions (via scenarios and task/flow
> analysis)

***I completely agree with you, but I thought we were discussing design
phase activities here. :-) I consider all of the above activities to be part
of my discovery phase--that is, figuring out what I'm going to design for
whom and why. Conceptual modeling is where I start translating user needs
into solutions--an early design phase activity.

> Note that the scenarios mentioned above aren't quite the same as
> use cases in that they focus on the qualitative user experience
> (meeting goals, eliminating extraneous tasks) as well as data flow
> between system and human.

***This would be part of conceptual modeling. Ideally, scenarios of one kind
or another come into every phase of our work. :-) You can do a lot of this
analysis on a whiteboard though. Sketch various solutions, see if they
scale, or are applicable across different functionality, then choose one
solution for elaboration during the design phase.

> If you are able to follow these steps, you'll find that your
> objects and actions naturally follow from the behaviors, goals
> and needs of users as explored in your scenarios, which
> allows you to see even more clearly the relationships and
> task flows between object and actions you've identified.

***Of course, they do. It's also unfortunately true that, in some corporate
cultures, those early activities are given short shrift, so sometimes one
has to do guerilla user research. On occasion, I've even had to conceal all
of the work I've been doing to ascertain user needs or have been obstructed
by management from having direct contact with users. Stupid, I know, but
that's the way things sometimes are. I'm as good an advocate for good
practice as anyone I know, but there's not a lot one can do when such
attitudes come from executive management, and they're intractable. Yelling
back at the President of the company isn't generally great for longevity in
one's job. ;-) Better to be subtle and do what one can over time. :-)

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

20 Jul 2004 - 9:05am
Elizabeth Buie
2004

David Heller writes:

<<Hi elizabeth, I wasn't saying what I preferred, I was describing what I
have
found to be the culture of the institutions where I have worked..>>

Yes, I understood that. I was saying that I have found a culture very
different from what you have experienced.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland
301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

19 Jul 2004 - 5:03pm
Bill Simons
2004

> Elizabeth Buie writes:
>
> I have found that software engineers have different levels of
> skills and sensitivities/sensibilities when it comes to
> interaction design, but most of them do want to contribute to
> the design. If an SWE has no skill in interaction design I'd
> rather they didn't try to > get in on the act, but I'd far
> rather collaborate with an SWE who "gets it" and can work
> *with* me, than throw my designs over the transom to one who
> just wants to "do what they're told".

As a software developer interested in interaction design, I
agree.

Engineers are, of course, very much locked on developing a
product to specification. That's what we're paid for! Meeting
functional requirements must be the minimal engineering goal.
Beyond that, time and other constraints dictate what else is
possible.

Sometimes "ease of use" is required, sometimes not. Personally I
feel that if people are going to use the software (as opposed to
back room number crunching) then we should be designing and
testing for usability as much as is affordable.

Yes, engineers have a different focus from pure designers, but
that doesn't mean we can't adopt some of the designers'
sensibilities.

Bill Simons

--
Software Developer
Landmark Graphics Corporation

20 Jul 2004 - 4:02am
Martyn Jones BSc
2004

> Pabini Gabriel-Petit wrote:
>
> I completely agree that analyzing object and actions is
> an important step in the conceptual modeling phase of a
> design. However, the steps that lead up to it are
> equally critical:
>
> 1) Understanding who the users are (via market and ethnographic research)
> 2) Understanding their goals/motivations in the context of the product
> (via personas and other user modeling/analysis)
> 3) Identifying user needs from goals (via user models and context
> scenarios)
> 4) Translating needs into objects and actions (via scenarios and task/flow
> analysis)

The above sounds comprehensive enough - my problem is that the timescale of
the projects I work on varies from weeks to months (up to half a year).
Desparately seeking scalable models that I can apply versions of to all
projects.

I come from a Computer Science background - but am now totally focused on
New Media / Interaction Design. Most of the projects lifecycles models I
know of are too cumbersome and inflexible to be used for the smaller scale
projects. More often than not, we revert to the incremental prototyping
method (mostly because some clients don't know what they want until they see
it - or because of our inability to communicate value in terms they can
relate to).

We often have requests for 'crazy' UIs because the client has seen something
similar on the Nike site etc. This is frustrating because the emphasis of
the project becomes the 'bells and whistles', whilst issues such as
Accessibility take a back seat. Would be helpful if there was some type of
government body, whom could offer free advice to clients about best
practises and preferred supplier lists?!?!

Martyn

20 Jul 2004 - 10:36am
Robert Reimann
2003

Pabini wrote:

> ***I completely agree with you, but I thought we were discussing design
phase activities here. :-)

I think the original question was a request for design
methodologies.

In the broad sense, discovery has to be an integral
part of design, and IMO designers need to participate
heavily in the discovery phase for it to be of value
in the later phases.

> You can do a lot of this analysis on a whiteboard though.

Absolutely. I'm used to whiteboards being a primary
design tool at the concept phase.

> so sometimes one has to do guerilla user research. On
> occasion, I've even had to conceal all of the work I've
> been doing to ascertain user needs or have been obstructed
> by management from having direct contact with users.

Been there, done that. :^) It's unfortunate, but in these
cases you need to produce great results before people's
minds will change. But that change can happen if you can
navigate the politics of the organization successfully.
That's the advocacy/evangelist role of the designer; it's
easier in some audiences/organizations than in others....

Robert.

-----Original Message-----
From: Pabini Gabriel-Petit [mailto:pabini at earthlink.net]
Sent: Tuesday, July 20, 2004 7:11 AM
To: Reimann, Robert;
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: Re: [ID Discuss] Design Methodology for GUI development

Robert Reimann wrote:

> I completely agree that analyzing object and actions is
> an important step in the conceptual modeling phase of a design.
> However, the steps that lead up to it are equally critical:
>
> 1) Understanding who the users are (via market and ethnographic
> research)
> 2) Understanding their goals/motivations in the context of the product
> (via personas and other user modeling/analysis)
> 3) Identifying user needs from goals (via user models and context
scenarios)
> 4) Translating needs into objects and actions (via scenarios and
> task/flow
> analysis)

***I completely agree with you, but I thought we were discussing design
phase activities here. :-) I consider all of the above activities to be part
of my discovery phase--that is, figuring out what I'm going to design for
whom and why. Conceptual modeling is where I start translating user needs
into solutions--an early design phase activity.

> Note that the scenarios mentioned above aren't quite the same as use
> cases in that they focus on the qualitative user experience (meeting
> goals, eliminating extraneous tasks) as well as data flow between
> system and human.

***This would be part of conceptual modeling. Ideally, scenarios of one kind
or another come into every phase of our work. :-) You can do a lot of this
analysis on a whiteboard though. Sketch various solutions, see if they
scale, or are applicable across different functionality, then choose one
solution for elaboration during the design phase.

> If you are able to follow these steps, you'll find that your objects
> and actions naturally follow from the behaviors, goals and needs of
> users as explored in your scenarios, which allows you to see even more
> clearly the relationships and task flows between object and actions
> you've identified.

***Of course, they do. It's also unfortunately true that, in some corporate
cultures, those early activities are given short shrift, so sometimes one
has to do guerilla user research. On occasion, I've even had to conceal all
of the work I've been doing to ascertain user needs or have been obstructed
by management from having direct contact with users. Stupid, I know, but
that's the way things sometimes are. I'm as good an advocate for good
practice as anyone I know, but there's not a lot one can do when such
attitudes come from executive management, and they're intractable. Yelling
back at the President of the company isn't generally great for longevity in
one's job. ;-) Better to be subtle and do what one can over time. :-)

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

20 Jul 2004 - 12:59pm
Greg Petroff
2004

Talking about Guerilla Research:

Recently I concealed a persona exercise I wanted to get done for a website
we needed to develop within the context of a greater "branding exercise"
for the client. Using Personas for brand building is a well established
process that we were able to sell to managment from a "you need to know who
and how to talk to your customer." By tacking onto this we were able to
get the detail we needed for our project. We even were able to validate
our ideas with real customers as part of the "branding effort" being
tested.

We involved senior management in the process as they had the most tacit
knowledge of the customers and were in fact brilliant in describing who
they were, what their needs were etc.

Gregory Petroff
desk 212 383 4092
mobile 646 387 2841

|---------+----------------------------------------------------------------------->
| | "Reimann, Robert" <Robert_Reimann at bose.com> |
| | Sent by: |
| | discuss-interactiondesigners.com-bounces at lists.interactionde|
| | signers.com |
| | |
| | |
| | 07/20/2004 11:36 AM |
| | |
|---------+----------------------------------------------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'Pabini Gabriel-Petit'" <pabini at earthlink.net>, |
| discuss-interactiondesigners.com at lists.interactiondesigners.com |
| cc: (bcc: Greg Petroff/SIAC) |
| Subject: RE: [ID Discuss] Design Methodology for GUI development |
>------------------------------------------------------------------------------------------------------------------------------|

> ----------
> From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com on
behalf of Reimann, Robert[SMTP:ROBERT_REIMANN at BOSE.COM]
> Sent: Tuesday, July 20, 2004 5:36:59 PM
> To: 'Pabini Gabriel-Petit';
>
discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: RE: [ID Discuss] Design Methodology for GUI development
> Auto forwarded by a Rule
>
>
Pabini wrote:

> ***I completely agree with you, but I thought we were discussing design
phase activities here. :-)

I think the original question was a request for design
methodologies.

In the broad sense, discovery has to be an integral
part of design, and IMO designers need to participate
heavily in the discovery phase for it to be of value
in the later phases.

> You can do a lot of this analysis on a whiteboard though.

Absolutely. I'm used to whiteboards being a primary
design tool at the concept phase.

> so sometimes one has to do guerilla user research. On
> occasion, I've even had to conceal all of the work I've
> been doing to ascertain user needs or have been obstructed
> by management from having direct contact with users.

Been there, done that. :^) It's unfortunate, but in these
cases you need to produce great results before people's
minds will change. But that change can happen if you can
navigate the politics of the organization successfully.
That's the advocacy/evangelist role of the designer; it's
easier in some audiences/organizations than in others....

Robert.

-----Original Message-----
From: Pabini Gabriel-Petit [mailto:pabini at earthlink.net]
Sent: Tuesday, July 20, 2004 7:11 AM
To: Reimann, Robert;
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: Re: [ID Discuss] Design Methodology for GUI development

Robert Reimann wrote:

> I completely agree that analyzing object and actions is
> an important step in the conceptual modeling phase of a design.
> However, the steps that lead up to it are equally critical:
>
> 1) Understanding who the users are (via market and ethnographic
> research)
> 2) Understanding their goals/motivations in the context of the product
> (via personas and other user modeling/analysis)
> 3) Identifying user needs from goals (via user models and context
scenarios)
> 4) Translating needs into objects and actions (via scenarios and
> task/flow
> analysis)

***I completely agree with you, but I thought we were discussing design
phase activities here. :-) I consider all of the above activities to be
part
of my discovery phase--that is, figuring out what I'm going to design for
whom and why. Conceptual modeling is where I start translating user needs
into solutions--an early design phase activity.

> Note that the scenarios mentioned above aren't quite the same as use
> cases in that they focus on the qualitative user experience (meeting
> goals, eliminating extraneous tasks) as well as data flow between
> system and human.

***This would be part of conceptual modeling. Ideally, scenarios of one
kind
or another come into every phase of our work. :-) You can do a lot of this
analysis on a whiteboard though. Sketch various solutions, see if they
scale, or are applicable across different functionality, then choose one
solution for elaboration during the design phase.

> If you are able to follow these steps, you'll find that your objects
> and actions naturally follow from the behaviors, goals and needs of
> users as explored in your scenarios, which allows you to see even more
> clearly the relationships and task flows between object and actions
> you've identified.

***Of course, they do. It's also unfortunately true that, in some corporate
cultures, those early activities are given short shrift, so sometimes one
has to do guerilla user research. On occasion, I've even had to conceal all
of the work I've been doing to ascertain user needs or have been obstructed
by management from having direct contact with users. Stupid, I know, but
that's the way things sometimes are. I'm as good an advocate for good
practice as anyone I know, but there's not a lot one can do when such
attitudes come from executive management, and they're intractable. Yelling
back at the President of the company isn't generally great for longevity in
one's job. ;-) Better to be subtle and do what one can over time. :-)

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

-----------------------------------------
This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer.

21 Jul 2004 - 11:19pm
pabini
2004

Robert Reimann wrote: In the broad sense, discovery has to be an integral
> part of design, and IMO designers need to participate
> heavily in the discovery phase for it to be of value
> in the later phases.

***I do think that discovery is an essential *precursor* to design. Without
discovery, you'd be a ship without a compass. I totally agree with you about
the benefits of doing the discovery oneself, but view discovery activities
as separate from design, primarily because, at that stage, I want to
maintain objectivity and keep an open mind. By the time I get to design, I
have lots of opinions. :-)

> > [Pabini] so sometimes one has to do guerilla user research. On
> > occasion, I've even had to conceal all of the work I've
> > been doing to ascertain user needs or have been obstructed
> > by management from having direct contact with users.
>
> [Robert] Been there, done that. :^) It's unfortunate, but in these
> cases you need to produce great results before people's
> minds will change. But that change can happen if you can
> navigate the politics of the organization successfully.
> That's the advocacy/evangelist role of the designer; it's
> easier in some audiences/organizations than in others....

***Yeah. Haven't we all. :-) If you produce great results, they'll tell you
that you don't need user research, because things are going great without
it. ;-) One can influence many for the good, most of the time, but not all
of the people, all of the time. And some companies are political minefields,
whereas others are more rational.

21 Jul 2004 - 11:30pm
pabini
2004

Hi Martyn

Actually, it was Robert Reimann who said this, not me: > > I completely
agree that analyzing object and actions is
> > an important step in the conceptual modeling phase of a
> > design. However, the steps that lead up to it are
> > equally critical:
> >
> > 1) Understanding who the users are (via market and ethnographic
research)
> > 2) Understanding their goals/motivations in the context of the product
> > (via personas and other user modeling/analysis)
> > 3) Identifying user needs from goals (via user models and context
> > scenarios)
> > 4) Translating needs into objects and actions (via scenarios and
task/flow
> > analysis)
>
> The above sounds comprehensive enough - my problem is that the timescale
of
> the projects I work on varies from weeks to months (up to half a year).
> Desparately seeking scalable models that I can apply versions of to all
> projects.

This is a reality we all face. One really has to tailor one methods to the
project at hand. When doing that, I think it's better to maintain the
breadth rather than the depth of your methods.

Pabini Gabriel-Petit

26 Jul 2004 - 8:28pm
cfmdesigns
2004

Pabini Gabriel-Petit <pabini at earthlink.net> writes:

>Peter Boersma wrote: Writing long specs is what I try to avoid at all costs.
>>
> > Putting the bare minimum of specifications in the wireframes
>(with some room
>> for notes), and deferring details of the working of global elements to
>> seperate lean & mean documents is my preferred way to go.
>
>***[PGP] I can see from your title that you work on Web sites. Web
>sites--because of the limits of the technology behind them--are typically
>very simple stuff from an interaction design viewpoint. It's mainly
>navigation. I predominantly work on very complex desktop software and Web
>applications implemented as binary code for specific platforms. If I didn't
>write detailed specs, I'd basically be telling the engineers to implement
>interactions in any way they liked. When I design Web applications
>implemented in HTML, I still write specs, but obviously they're
>comparatively brief. I don't generally work on Web sites, but in that case,
>annotated wireframes might be sufficient.

I think you are downplaying web apps here.

Having done software testing on web apps, handheld device apps which
communicated with servers, and complex desktop apps with and without
server access features, there really isn't much difference on the QE
end. Web apps are a heck of a lot more than just HTML navigation,
once you throw Java and database interactions in.

There does tend to be a level of difference, but it's in the "number
of features" arena, not in the complexity or sophistication. This
limits the user interactions, but it's more because of the Internet
chokepoint -- how much you can depend on the user's system to do and
how much data you can get to and from the server without delaying the
user too long -- than because of limits on what can be done overall;
it's an economic limit more than a programmatic one. The specs --
both Dev and UI -- have tended to be equivalently thick and complex
(or often, just as sparse and minimal and devoid of the content QE
needs to not have to flail around in the dark).
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 07/20)

28 Jul 2004 - 9:01am
pabini
2004

Jim Drew wrote: I think you are downplaying web apps here.

***PGP Not at all. My remark about interaction design being largely limited
to navigation was in reference only to Web sites. I made a distinction
between Web applications and Web sites. However, the standard widget set is
much more limited in HTML than for a desktop operating system.

> Having done software testing on web apps, handheld device apps which
> communicated with servers, and complex desktop apps with and without
> server access features, there really isn't much difference on the QE
> end. Web apps are a heck of a lot more than just HTML navigation,
> once you throw Java and database interactions in.

> There does tend to be a level of difference, but it's in the "number
> of features" arena, not in the complexity or sophistication. This
> limits the user interactions, but it's more because of the Internet
> chokepoint -- how much you can depend on the user's system to do and
> how much data you can get to and from the server without delaying the
> user too long -- than because of limits on what can be done overall;
> it's an economic limit more than a programmatic one. The specs --
> both Dev and UI -- have tended to be equivalently thick and complex
> (or often, just as sparse and minimal and devoid of the content QE
> needs to not have to flail around in the dark).

***PGP It really depends on the application, but in general, most Web
applications tend to be both simpler in their functionality and more limited
in scale than the kinds of complex desktop applications I typically work on.
However, there are, of course, complex Web apps and simple desktop
applications. I see you agree with me that there are practical limits that
determine the complexity of Web applications. The whole point of my comments
on simple versus complex was that the more complex an application is, the
longer and more detailed its spec should be. I'm very glad we agree on the
importance of good, detailed specifications to an entire product development
team. Team members flailing around in the dark is definitely not a good
thing. :-)

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

Syndicate content Get the feed