IA terminology

14 Jun 2005 - 10:24am
9 years ago
10 replies
671 reads
Wendy Fischer
2004

I am wondering what people use for terminology regarding sitemaps/interaction flows in regards to communicating deliverables to people who don't have an interaction design/information architecture background. I am using sitemaps/interaction flows both and I find that the PM's are getting confused on what the terminology is, so I just want to settle on one term to simplify things for them.

I always associate site maps with "content" and associate interaction flows with "application design" or "transactions". However, essentially there can be a lot of interchange between the two, particularly if you have an application within the context of your content. Regardless of what type of design I am doing,

I still use the same notation for both sitemaps/interaction flows (I've settled on Jesse James Garrett's visual vocabulary notation, which is excellent by the way) and they are both communicated to the product manager/development/profressional services in the same format, and often mixed, particulary if the content has a transaction in it. They are often mixed, depending on what the content is (we have a hierarchy for an ecommerce storefront and transaction for purchasing content).

Any ideas?

-Wendy

Comments

14 Jun 2005 - 11:03am
Peter Merholz
2004

Wendy Fischer wrote:

> I am wondering what people use for terminology regarding sitemaps/
> interaction flows in regards to communicating deliverables to
> people who don't have an interaction design/information
> architecture background. I am using sitemaps/interaction flows
> both and I find that the PM's are getting confused on what the
> terminology is, so I just want to settle on one term to simplify
> things for them.

My first idea is that this is a discussion better suited to an IA
mailing list, such as SIGIA or the IA Institute's members list.
However, it was asked here, so here goes.

At Adaptive Path, we refer to the boxes-and-arrows diagrams that
depict a site's structure as an "architecture diagram." We explicitly
do NOT call it a "site map," because that has another, different,
meaning - the page on a web site that shows you all the other pages.
While the two are obviously related, they are also different.

You can use "architecture diagram" for interaction flows as well.

For what it's worth, we refer to the page designs as "wireframes".

--peter

14 Jun 2005 - 11:57am
Todd Warfel
2003

On Jun 14, 2005, at 11:24 AM, Wendy Fischer wrote:

> I always associate site maps with "content" and associate
> interaction flows with "application design" or "transactions".
> However, essentially there can be a lot of interchange between the
> two, particularly if you have an application within the context of
> your content. Regardless of what type of design I am doing,

We use the following terms:

1. Site Structure - visual representation of the site's or
application's overall organizational model. This focuses on the
relationship of content and functionality to each other. One
difference for us is that our site structures do not use boxes and
arrows, but rather is based on a model we developed several years
that's more of a hub-and-spoke model.

2. Taskflow Diagrams - visual representation of the interaction,
processes, and tasks that can be performed in a site or application.
We typically show authentication, non-authentication, dependencies,
and "global elements" or "common components." So, our taskflow
diagrams are more than standard boxes and arrows type flows as well.

3. Task Analysis Grid - a matrix that shows all the task and subtasks
a customer/consumer/actor/user might perform in relation to the site
or application we design. This includes tasks they might need to
complete that might even be outside the scope of what we're working
on. This is important, as this helps us address influencers that
might be outside our product, but impact the persons' interaction
with our product. Also, this acts as our giant "checklist" to make
sure we don't miss anything.

4. Wireframes - blueprints of the screen design that show how each of
the items specified in both the Site Structure and the Taskflow
Diagrams relate to each other at a screen level. We've stopped using
the term "page" and have replaced it with "screen" since the page
paradigm is dying thanks to RIAs.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: twarfel at mac.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
Problems are just opportunities for success.

14 Jun 2005 - 12:45pm
Peter Boersma
2003

Wendy Fischer said:
> I am wondering what people use for terminology regarding
> sitemaps/interaction flows in regards to communicating deliverables to
> people who don't have an interaction design/information architecture
> background.

Not having a background in our field doesn't necessarily mean "unable to
learn two new terms for things", does it? ;-)

> I always associate site maps with "content" and associate interaction
> flows with "application design" or "transactions". However,
> essentially there can be a lot of interchange between the two,
> particularly if you have an application within the context of your
> content.

If you want to keep using two terms, make sure there is as little
interchange between the two, i.e. sacrifice some details in one if this
allows you to make the distinction clearer.

Just as PeterMe said, "sitemap" has a specific meaning for a lot of people
and is therefore best avoided.

In my last company, where we designed transactional web applications
(interactive) that had to fit into a portal (semi-static content), we did
combine the two into one deliverable called "screenflow". But we allowed for
several levels of detail from site-architecture-like high-level flows for
the content-rich pages to detailed interaction flows for the transactional
pages. The lower level details were hidden when the high-level flows were
shown. (see: http://www.xs4all.nl/~nieuwnet/iasummit/ for a presentation we
gave at the 2004 IA Summit about this tool, and more specifically the
exported-to-HTML version of it, the "J-Flow").

> I still use the same notation for both sitemaps/interaction flows (I've
> settled on Jesse James Garrett's visual vocabulary notation, which is
> excellent by the way) and they are both communicated to the product
> manager/development/profressional services in the same format, and
> often mixed, particulary if the content has a transaction in it. They
> are often mixed, depending on what the content is (we have a hierarchy
> for an ecommerce storefront and transaction for purchasing content).

This may add to the confusion, unless you truly integrate the two into one
deliverable...

Peter
--
Peter Boersma | Consultant User Experience
Koggestraat 10A | 1012 TA | Amsterdam | The Netherlands
phone: +31(0)206245641 | mobile: +31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com

14 Jun 2005 - 1:08pm
Wendy Fischer
2004

Architecture diagram makes sense. I am already using "wireframe" to represent black/white page design.

As for whether this topic is relevant to the list or not, I tend to disagree.

The discussion guidelines state:

"The Interaction Design Group (IxDG) sponsors IxD Discussion to provide a forum for the discussion of interaction design issues, best practices, and methods among practitioners, teachers, and students of interaction design and others who are interested in interaction design. All discussions on this list must relate to interaction design. While discussions may encompass disciplines such as user-centered design, information architecture, or visual design as they relate to interaction design, please keep the primary focus of your topics of discussion on interaction design. For example, a discussion of color theory would be out of place here, but one about the best highlight color for required values would be perfectly appropriate."

I would associate this question with best practices as it relates to interaction design. It's a combination of terminology as it applies to interaction design with a sprinkle of information architecture thrown in.

I might have phrased it a bit more on the information architecture side, since my use case examples illustrate information architecture with interaction flows contained within the information architecture hierarchy. However my interest and practice is on the interaction design side, hence I really have no desire to join information architecture mailing lists since it's approximately about 3% of what I do. I already belong to enough UCD/usability/interaction design lists, I don't need to add two more.

Wendy Fischer

Peter Merholz <peterme at peterme.com> wrote:
[Please voluntarily trim replies to include only relevant quoted material.]

Wendy Fischer wrote:

> I am wondering what people use for terminology regarding sitemaps/
> interaction flows in regards to communicating deliverables to
> people who don't have an interaction design/information
> architecture background. I am using sitemaps/interaction flows
> both and I find that the PM's are getting confused on what the
> terminology is, so I just want to settle on one term to simplify
> things for them.

My first idea is that this is a discussion better suited to an IA
mailing list, such as SIGIA or the IA Institute's members list.
However, it was asked here, so here goes.

At Adaptive Path, we refer to the boxes-and-arrows diagrams that
depict a site's structure as an "architecture diagram." We explicitly
do NOT call it a "site map," because that has another, different,
meaning - the page on a web site that shows you all the other pages.
While the two are obviously related, they are also different.

You can use "architecture diagram" for interaction flows as well.

For what it's worth, we refer to the page designs as "wireframes".

--peter
_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

14 Jun 2005 - 1:33pm
Wendy Fischer
2004

The product managers are able to learn new things. However, I initially made the assumption that the product managers I am working with knew about interaction design/design terminology because they had been working with a previous interaction designer before me who had "educated" them.

However, my assumption was quickly overturned when one of the product managers pointed out that a technical product manager (in this case, somebody who writes functional specifications) was doing visual design because he had done mockups in Microsoft Paint. I had to point out that it wasn't visual design, but it was a "wireframe" (though the developers, I am sure, would make it look exactly like the mockup in the spec).

Right now I am going through the procedure of putting a process in place and also educating the product managers about UCD/interaction design/usability/etc. Due to the fact that there is one of me, and the broad span of design that I am doing (mobile UI, enterprise CMS web interace, consumer based ecommerce website, perhaps a little Eclipse), I am trying to keep the terminology general for now, then expand it as we add products/resources, etc.

I would describe IA work at 3% of my job; the rest is interaction design. I do tend to mix the information architecture diagrams/interaction flows together due to the fact that 1) it's all part of the same deliverable anyway;and 2)I've found the architecture diagrams useful for the developers who like to see how everything flows and how everything is connected, particularly if there is a transaction buried down in the content hierarchy.

-Wendy Fischer

Peter Boersma <peter at peterboersma.com> wrote:
Wendy Fischer said:
> I am wondering what people use for terminology regarding
> sitemaps/interaction flows in regards to communicating deliverables to
> people who don't have an interaction design/information architecture
> background.

Not having a background in our field doesn't necessarily mean "unable to
learn two new terms for things", does it? ;-)

> I always associate site maps with "content" and associate interaction
> flows with "application design" or "transactions". However,
> essentially there can be a lot of interchange between the two,
> particularly if you have an application within the context of your
> content.

If you want to keep using two terms, make sure there is as little
interchange between the two, i.e. sacrifice some details in one if this
allows you to make the distinction clearer.

Just as PeterMe said, "sitemap" has a specific meaning for a lot of people
and is therefore best avoided.

In my last company, where we designed transactional web applications
(interactive) that had to fit into a portal (semi-static content), we did
combine the two into one deliverable called "screenflow". But we allowed for
several levels of detail from site-architecture-like high-level flows for
the content-rich pages to detailed interaction flows for the transactional
pages. The lower level details were hidden when the high-level flows were
shown. (see: http://www.xs4all.nl/~nieuwnet/iasummit/ for a presentation we
gave at the 2004 IA Summit about this tool, and more specifically the
exported-to-HTML version of it, the "J-Flow").

> I still use the same notation for both sitemaps/interaction flows (I've
> settled on Jesse James Garrett's visual vocabulary notation, which is
> excellent by the way) and they are both communicated to the product
> manager/development/profressional services in the same format, and
> often mixed, particulary if the content has a transaction in it. They
> are often mixed, depending on what the content is (we have a hierarchy
> for an ecommerce storefront and transaction for purchasing content).

This may add to the confusion, unless you truly integrate the two into one
deliverable...

Peter
--
Peter Boersma | Consultant User Experience
Koggestraat 10A | 1012 TA | Amsterdam | The Netherlands
phone: +31(0)206245641 | mobile: +31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com

14 Jun 2005 - 2:40pm
Peter Boersma
2003

Wendy Fischer said:
> Right now I am going through the procedure of putting a process in
> place and also educating the product managers about UCD/interaction
> design/usability/etc.

I hate to blow my own horn twice, but in that case you may want to have a
look at my contribution to this year's IA Summit:
"StUX - integrating IA deliverables in a software development methodology"
http://www.peterboersma.com/blog/2005/03/my-ia-summit-presentation-stux_10.html(warning, long URL, this is a shorter version: http://tinyurl.com/dffef )

In the prsentation, I describe how my company developed a series of UCD
add-ons to an existing software development methodology (in our case the
Rational Unified Process, RUP). We identified roles, deliverables and their
relationships with a small team of people. In the latter part I show
examples of how other (smaller and bigger) companies have done the same.

> I do tend to mix the information architecture
> diagrams/interaction flows together due to the fact that 1) it's all
> part of the same deliverable anyway;and 2)I've found the architecture
> diagrams useful for the developers who like to see how everything flows
> and how everything is connected, particularly if there is a transaction
> buried down in the content hierarchy.

Reason number 1 seems to contradict what you wrote in your original question
("I still use the same notation for both sitemaps/interaction flows"), or am
I reading something in there that isn't? Reasons number 2 doesn't contradict
the development of specialized deliverabes for specialized
purposes/audiences...
Peter
--
Peter Boersma | Consultant User Experience
Koggestraat 10A | 1012 TA | Amsterdam | The Netherlands
phone: +31(0)206245641 | mobile: +31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com

14 Jun 2005 - 3:14pm
Wendy Fischer
2004

Right now I have a pipeline to work from, I wouldn't call it a process per se.

1) The Visual Vocabularly supports both IA and interaction design, as far as I am concerned. I mix IA/interaction flows anyway regardless. Ultimately it's being communicated in the same template with the same intent. However, due to the fact that I have done a lot of interaction design, I do tend separate interaction flows from IA diagrams in my mind. It's probably more of a mental and semantical issue to me personally than anything else.

However, it also raises the reason of why I asked about general terms regarding terminology of communicating the intent of sitemaps/IA diagrams/interaction flows

2) Since I'm pretty much starting from ground zero, I am keeping it basic but including the essentials, which to me is architecture diagrams, then wireframes as a starting point (this just being part of the UCD process/activities/deliverables..). I'm trying to raise the bar of what the expectation should be in regards to 1) UCD process 2) types of deliverables and 3) purposes of deliverables. Ultimately to me, I am looking at the page flow, regardless of whether it's content or transaction based, and trying to determine a) what the logic is of how the user flows through the experience b) how to minimize the click rate where possible (particularly important for cell phones) c) recognize design patterns and d) figure out how to organize the navigation.

The target audience for the architecure diagrams are product managers, technical product managers and the developers. These may go out to a client, but for the most part they won't.

The PMs like the diagrams because they can see from a higher level their product roadmap come to fruition. The technical PM's like the logic, particularly if I only have time to do the sitemaps and they are doing the wireframes. The developers like the architecture diagrams because it provides them a map from which they can start building from (particularly if they haven't done their own system diagram). Most of all the architectural diagrams are useful for discussion and review among all the team members, before I transition into the detailed design.

At this point, I don't have the time or the luxury of doing "specialized deliverables". There is no expectation from anyone of that; they're happy that they are getting more than they had. At some point as the company/process/UCD practice matures, there may be more expectation and need for specialized deliverables depending on the project/resources, but currently there is none.

-Wendy
Peter Boersma <peter at peterboersma.com> wrote:
Wendy Fischer said:
> Right now I am going through the procedure of putting a process in
> place and also educating the product managers about UCD/interaction
> design/usability/etc.

I hate to blow my own horn twice, but in that case you may want to have a
look at my contribution to this year's IA Summit:
"StUX - integrating IA deliverables in a software development methodology"
http://www.peterboersma.com/blog/2005/03/my-ia-summit-presentation-stux_10.html(warning, long URL, this is a shorter version: http://tinyurl.com/dffef )

In the prsentation, I describe how my company developed a series of UCD
add-ons to an existing software development methodology (in our case the
Rational Unified Process, RUP). We identified roles, deliverables and their
relationships with a small team of people. In the latter part I show
examples of how other (smaller and bigger) companies have done the same.

> I do tend to mix the information architecture
> diagrams/interaction flows together due to the fact that 1) it's all
> part of the same deliverable anyway;and 2)I've found the architecture
> diagrams useful for the developers who like to see how everything flows
> and how everything is connected, particularly if there is a transaction
> buried down in the content hierarchy.

Reason number 1 seems to contradict what you wrote in your original question
("I still use the same notation for both sitemaps/interaction flows"), or am
I reading something in there that isn't? Reasons number 2 doesn't contradict
the development of specialized deliverabes for specialized
purposes/audiences...
Peter
--
Peter Boersma | Consultant User Experience
Koggestraat 10A | 1012 TA | Amsterdam | The Netherlands
phone: +31(0)206245641 | mobile: +31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com

15 Jun 2005 - 3:02am
Lilly Irani
2004

I've actually had trouble getting product managers to get their heads
around the problem when I use the visual vocabulary (maybe I'm not
using it properly). I find that making a wireframe flow better engages
and informs the PMs I work with. (And, yes, I guess I call it a
wireframe flow because it's a flow diagram with small wireframes of
the screens with major interactions and control logic highlighted.)

All in all, I adjust what I produce and what I call it to the needs of
the team. I work in an organization that is hiring a lot right now, so
training each new manager I work with in more standard IA deliverables
hasn't proved effective for getting insightful discussions and
meaningful buy-in.

~lilly

On 6/14/05, Wendy Fischer <erpdesigner at yahoo.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I am wondering what people use for terminology regarding sitemaps/interaction flows in regards to communicating deliverables to people who don't have an interaction design/information architecture background. I am using sitemaps/interaction flows both and I find that the PM's are getting confused on what the terminology is, so I just want to settle on one term to simplify things for them.
>
> I always associate site maps with "content" and associate interaction flows with "application design" or "transactions". However, essentially there can be a lot of interchange between the two, particularly if you have an application within the context of your content. Regardless of what type of design I am doing,
>
> I still use the same notation for both sitemaps/interaction flows (I've settled on Jesse James Garrett's visual vocabulary notation, which is excellent by the way) and they are both communicated to the product manager/development/profressional services in the same format, and often mixed, particulary if the content has a transaction in it. They are often mixed, depending on what the content is (we have a hierarchy for an ecommerce storefront and transaction for purchasing content).
>
> Any ideas?
>
> -Wendy
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

15 Jun 2005 - 8:43am
Wendy Fischer
2004

We use a wiki for our intranet, so I posted a section with examples up on the wiki and with the Visual Vocabulary cheat sheet.

The PM's are more business types, I think that they understand the boxes and the arrows and the flows, I can't necessarily say they understand the blood and guts but they can follow it.

The technical PM's tend to be former software and they are excellent at understanding diagrams. In my current job, the PM's are responsible for the Marketing Requirements and the TPM's are responsible for the Functional Specifications/Technical Requirements.

The developers appear to understand it. I would say that they very much appreciated having the flows to use as a "Map" particularly since for my last project I gave them a semi-interactive prototype.

Lilly Irani <lilly.irani at gmail.com> wrote:
I've actually had trouble getting product managers to get their heads
around the problem when I use the visual vocabulary (maybe I'm not
using it properly). I find that making a wireframe flow better engages
and informs the PMs I work with. (And, yes, I guess I call it a
wireframe flow because it's a flow diagram with small wireframes of
the screens with major interactions and control logic highlighted.)

All in all, I adjust what I produce and what I call it to the needs of
the team. I work in an organization that is hiring a lot right now, so
training each new manager I work with in more standard IA deliverables
hasn't proved effective for getting insightful discussions and
meaningful buy-in.

~lilly

On 6/14/05, Wendy Fischer wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I am wondering what people use for terminology regarding sitemaps/interaction flows in regards to communicating deliverables to people who don't have an interaction design/information architecture background. I am using sitemaps/interaction flows both and I find that the PM's are getting confused on what the terminology is, so I just want to settle on one term to simplify things for them.
>
> I always associate site maps with "content" and associate interaction flows with "application design" or "transactions". However, essentially there can be a lot of interchange between the two, particularly if you have an application within the context of your content. Regardless of what type of design I am doing,
>
> I still use the same notation for both sitemaps/interaction flows (I've settled on Jesse James Garrett's visual vocabulary notation, which is excellent by the way) and they are both communicated to the product manager/development/profressional services in the same format, and often mixed, particulary if the content has a transaction in it. They are often mixed, depending on what the content is (we have a hierarchy for an ecommerce storefront and transaction for purchasing content).
>
> Any ideas?
>
> -Wendy
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

15 Jun 2005 - 11:28am
Lilly Irani
2004

Ah. Our projects tend to be done in small teams and by consensus, with
respect for persuasive expertise of the technical, UI, or management
expert on the team. So it our culture, any details missed by PMs and
techs in discussion deliverables early on tend to bite me in the but
later, so I try to be as expressive and low learning curve as I can.

~lilly

>
> The PM's are more business types, I think that they understand the boxes and
> the arrows and the flows, I can't necessarily say they understand the blood
> and guts but they can follow it.
>
> The technical PM's tend to be former software and they are excellent at
> understanding diagrams. In my current job, the PM's are responsible for the
> Marketing Requirements and the TPM's are responsible for the Functional
> Specifications/Technical Requirements.
>
> The developers appear to understand it. I would say that they very much
> appreciated having the flows to use as a "Map" particularly since for my
> last project I gave them a semi-interactive prototype.
>
> Lilly Irani <lilly.irani at gmail.com> wrote:
> I've actually had trouble getting product managers to get their heads
> around the problem when I use the visual vocabulary (maybe I'm not
> using it properly). I find that making a wireframe flow better engages
> and informs the PMs I work with. (And, yes, I guess I call it a
> wireframe flow because it's a flow diagram with small wireframes of
> the screens with major interactions and control logic highlighted.)
>
> All in all, I adjust what I produce and what I call it to the needs of
> the team. I work in an organization that is hiring a lot right now, so
> training each new manager I work with in more standard IA deliverables
> hasn't proved effective for getting insightful discussions and
> meaningful buy-in.
>
> ~lilly
>
> On 6/14/05, Wendy Fischer wrote:
> > [Please voluntarily trim replies to include only relevant quoted
> material.]
> >
> > I am wondering what people use for terminology regarding
> sitemaps/interaction flows in regards to communicating deliverables to
> people who don't have an interaction design/information architecture
> background. I am using sitemaps/interaction flows both and I find that the
> PM's are getting confused on what the terminology is, so I just want to
> settle on one term to simplify things for them.
> >
> > I always associate site maps with "content" and associate interaction
> flows with "application design" or "transactions". However, essentially
> there can be a lot of interchange between the two, particularly if you have
> an application within the context of your content. Regardless of what type
> of design I am doing,
> >
> > I still use the same notation for both sitemaps/interaction flows (I've
> settled on Jesse James Garrett's visual vocabulary notation, which is
> excellent by the way) and they are both communicated to the product
> manager/development/profressional services in the same
> format, and often mixed, particulary if the content has a transaction in it.
> They are often mixed, depending on what the content is (we have a hierarchy
> for an ecommerce storefront and transaction for purchasing content).
> >
> > Any ideas?
> >
> > -Wendy
> >
> > _______________________________________________
> > Welcome to the Interaction Design Group!
> > To post to this list ....... discuss at ixdg.org
> > (Un)Subscription Options ... http://discuss.ixdg.org/
> > Announcements List .........
> http://subscribe-announce.ixdg.org/
> > Questions .................. lists at ixdg.org
> > Home ....................... http://ixdg.org/
> >
>

Syndicate content Get the feed