Information Architect vs Business Process Analyst

8 Feb 2006 - 10:25am
8 years ago
7 replies
1369 reads
Kinjal
2006

Can someone throw some light on the differences /similarities between Information Architect and Business Process Analyst role.

I appreciate the help

Thanks

Comments

8 Feb 2006 - 10:44am
Dan Saffer
2003

On Feb 8, 2006, at 7:25 AM, Kinjal wrote:

> Can someone throw some light on the differences /similarities
> between Information Architect and Business Process Analyst role.

This might be a better question for SIGIA or IAI, but my experience
has been this:

Business Analysts define the business goals and metrics. That is,
they take ill-defined desires ("We need to sell more ball bearings!")
and turn them into objectives that can have design solutions. ("We
need a website that will sell one million ball bearings a month.")

Information Architects provide means of exploring and finding the
information needed to complete a task, like buying ball bearings.
(Where are the specifications for ball bearings on the site?)

These are traditional roles. Someone having the title "business
analyst" or "information architect" could do the tasks that
traditionally fall to the other role depending on the organization.

Dan Saffer
Sr. Interaction Designer, Adaptive Path
http://www.adaptivepath.com
http://www.odannyboy.com

8 Feb 2006 - 10:49am
Kinjal
2006

Actually the detailed requirements I came across mentions:

* Conduct/support Process Modeling sessions to develop new Process Design, identifying changes to the existing flow/design
* Create new and modify existing detailed Process Models depicting the most effective approach

So I got was thinking this is different from Business Analyst... It says Business Process Analyst or Process Design Business Analyst .......

----- Original Message ----
From: Dan Saffer <dan at odannyboy.com>
To: discuss at lists.interactiondesigners.com
Sent: Wednesday, February 08, 2006 09:44:08
Subject: Re: [IxDA Discuss] Information Architect vs Business Process Analyst

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

On Feb 8, 2006, at 7:25 AM, Kinjal wrote:

> Can someone throw some light on the differences /similarities
> between Information Architect and Business Process Analyst role.

This might be a better question for SIGIA or IAI, but my experience
has been this:

Business Analysts define the business goals and metrics. That is,
they take ill-defined desires ("We need to sell more ball bearings!")
and turn them into objectives that can have design solutions. ("We
need a website that will sell one million ball bearings a month.")

Information Architects provide means of exploring and finding the
information needed to complete a task, like buying ball bearings.
(Where are the specifications for ball bearings on the site?)

These are traditional roles. Someone having the title "business
analyst" or "information architect" could do the tasks that
traditionally fall to the other role depending on the organization.

Dan Saffer
Sr. Interaction Designer, Adaptive Path
http://www.adaptivepath.com
http://www.odannyboy.com

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

8 Feb 2006 - 10:40am
uijeff at aol.com
2006

The short of it is:

Business Analysts define/describe the "what" -- what the system is,
what it needs to do, what features/functions it requires

IA's define the "how" -- how the system is implemented, what is the
hierarchy of information, features, etc...

I'm sure others on this list will dig into the details much deeper.

[Jeff]

-----Original Message-----
From: Kinjal <kinju_3 at yahoo.com>
To: discuss at lists.interactiondesigners.com
Sent: Wed, 8 Feb 2006 07:25:18 -0800 (PST)
Subject: [IxDA Discuss] Information Architect vs Business Process
Analyst

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

Can someone throw some light on the differences /similarities between
Information Architect and Business Process Analyst role.

I appreciate the help

Thanks

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

8 Feb 2006 - 12:07pm
Lisa Colvin
2005

Hi all-

Having been called a Business Systems Analyst, a Systems Analyst, an Information Architect and an Interaction Designer at various points in my career, I would say that in my case, the role has been reasonably similar - maybe because it's always _me_ doing the work. I have found that the title varies based on the industry also- for example- at financial companies, I'm an Analyst. In the entertainment and agency sector, I'm an IA or IxD. I also tend to work on web apps that interface with multiple systems - so I'm designing the front end with the creative team and collaborating with tech to connect to the back end. Often though as an analyst, I end up "doing it all" more often- whereas in the IA/IxD world, I have the support of content, visual, and tech prods.

Long story short - I have found that while "it depends" on the industry, company, role and individual (doesn't everything?) there are some differences.

Just my $.02.

Cheers-

Lisa

-----Original Message-----
>From: uijeff at aol.com
>Sent: Feb 8, 2006 7:40 AM
>To: kinju_3 at yahoo.com, discuss at lists.interactiondesigners.com
>Subject: Re: [IxDA Discuss] Information Architect vs Business Process Analyst
>
>[Please voluntarily trim replies to include only relevant quoted material.]
>
>The short of it is:
>
>Business Analysts define/describe the "what" -- what the system is,
>what it needs to do, what features/functions it requires
>
>IA's define the "how" -- how the system is implemented, what is the
>hierarchy of information, features, etc...
>
>I'm sure others on this list will dig into the details much deeper.
>
>[Jeff]
>
>
>
>
>
>
>
>-----Original Message-----
>From: Kinjal <kinju_3 at yahoo.com>
>To: discuss at lists.interactiondesigners.com
>Sent: Wed, 8 Feb 2006 07:25:18 -0800 (PST)
>Subject: [IxDA Discuss] Information Architect vs Business Process
>Analyst
>
> [Please voluntarily trim replies to include only relevant quoted
>material.]
>
>Can someone throw some light on the differences /similarities between
>Information Architect and Business Process Analyst role.
>
> I appreciate the help
>
> Thanks
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://listguide.ixda.org/
>List Help .................. http://listhelp.ixda.org/
>(Un)Subscription Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://listguide.ixda.org/
>List Help .................. http://listhelp.ixda.org/
>(Un)Subscription Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org

8 Feb 2006 - 12:06pm
Kristen Groh
2005

>
> Can someone throw some light on the differences /similarities between
> Information Architect and Business Process Analyst role.

The definition of this role can certainly vary depending on the organization
and the nature of the project.

As just one rather simple example, if the project is designing an e-commerce
Web site, a "Strategist" (or similar role) would determine what the business
goals are, ³we want to increase sales, we want to know if our investments
into the site are returning value, etc.," and break those down into some
strategic approaches like ³up-sell items based on user¹s activities on the
site, drive them to the sale on line, etc.²

The Business Analyst would then determine what information needs to be
collected and how the system needs to act to meet the business needs,
³collect information on: what they looked at as they surfed the site, what
they removed from their cart, what they have looked at in the past, where
they are dropping off if the sale isn¹t completed, etc. ² and ³The system
should: show related products at the time of sale, save items in the cart if
the user leaves before purchase, ask the users option of the site, etc.²
they would also cover other business needs: for the transaction (credit
card, etc.), shipping (address, etc.), etc.

That person would create process flow diagrams to show how a user flows
through the site, develop use-cases which state the user interaction and the
system response. I imagine, depending on the strengths of the Information
Architect, this could, and should be a joint effort

The Information Architect then organizes the site content, maps out the
on-page user functionality (its it a radio button, drop down, etc., it is
all on one page or divided into 3 pages?), defines the meta-data structure,
etc.

Obviously, there are several other examples...

----------------
Kristen Groh
Account Director
VSA Partners
http://www.vsapartners.com

kgroh at vsapartners.com

8 Feb 2006 - 12:51pm
Pierre Roberge
2005

I can talk a bit about BAs because there are a few BAs at my company. I
have not been in contact with BAs before so my opinion relates to the BAs
I currently work with. Here is what I learned observing them.

BAs look at the processes a company does and strive to improve them. First
they map what they call the ASIS process which encompasses all the
operations/functions performed across the company regardless of job
positions and departments. Then, they look at that process and look for
areas for improvements. Is there any redundancies, why a piece of paper
is copied 5 times and stores at 5 different places, etc. Then they work
on functional specifications for the systems that will support some of the
processes but also participate in changing the jobs people do,
create/elimindate/change processes/jobs, create departments, .... They
are a powerful bunch of people, at least at my company.

The good:
They describe the high level processes without mentionning the systems
that may be used. For example, they might have a process called *Get
customer information*. Whether or not someone will use a computer or not.
At the lower level, they will look at how each process is implemented.
That is good because they try to separate what needs to be done and how it
is being done. That way they can unmarry themselves with the current
systems and redefing what the systems should do. They have elaborate
methodologies to capture what is happening throughout a company. This is
something I can definitely use.

The bad:
I don't understand why they spend time mapping the ASIS of something that
they want to change. To me mapping the ASIS enclose them in a box and
then they can only make minor improvements. They also believe that once
the system they build support the improved processes, it is a good system.
They may design processes but they don't design interactions, they don't
look at how people's goals, work culture, constraints as well as, I
perceive them as glorified programmers. Since they don't look at goals,
they cannot revolutionize the current processes, they can only
incrementally improve them. What they produce is a functional
specification. No screens, no mention of how people work, their goals,
nothing. Just functions. System must computer this and that.

The ugly:
Another bad thing that frustrates me is that when I show them how I work
and the conclusion I came to using Cooper's methogology, they feel that
they would have come to the same conclusion with their methodology. They
see myself as a BA that designs interfaces. They only pay lip service to
studying goals people have and why they do things but when you look at
them interview people, they try to hammer these goals out of people's
mouth by asking 100 times the question "Why". It goes like this :
- Why do you do this?
- A
- Why do you do A
- B
- Why do you do B
and so on for hours.

This is a very lenghty process to try to get at people's goals and they
can never get to the high level ones. People are not that good at
introspection. They expect people to tell them everything they need to
know, like many builders/programmers. When people can't they say that the
business people are not strong/smart/experienced enough.

In summary, Cooper's methodology is way better at getting WHAT a system
should do to help people than their methodology and they have no
methodology to design the HOW a system should do it.

Anyway, that was my rant. Thank you for listening.

Have a good day!
Pierre Roberge
User Experience Designer / Business Analyst
Expert Travel Financial Securities (ETFS)
www.etfsinc.com
819.566.2901x2193

----------
Expert Travel Financial Security (E.T.F.S.) Inc. The information
transmitted is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon this information by persons or entities other
than the intended recipient, is prohibited. If you have received this
in error, please contact the sender and delete the material from any
computer. Unless otherwise stated, opinions expressed in this e-mail
are those of the author and are not endorsed by the author's employer.

Voyage Expert Sécurité Financière (E.T.F.S.) inc. L'information
transmise ne s'adresse qu'au particulier ou à l'organisme à qui il est
dirigé. Il peut contenir des renseignements de nature privilégiée et/ou
confidentielle . Si le lecteur de ce message n'est pas le destinataire
visé, ni l'employé ou le mandataire chargé de la livraison au
destinataire visé, il est par la présente avisé que toute dissémination,
distribution ou transcription de cette communication est strictement
interdite. Si vous avez reçu la présente communication par erreur,
veuillez nous en aviser immédiatement par courriel et détruire le
document de tout ordinateur le contenant. À moins d'avis contraire,
toute opinion exprimée dans le présent courriel est celle de son auteur
et n'est pas endossée par l'employeur de la personne qui l'exprime.

9 Feb 2006 - 7:40am
Louise Ferguson
2005

On 08/02/06, Pierre Roberge <Pierre.Roberge at etfsinc.com> wrote:
>
> <snip>
>

The ugly:

> Another bad thing that frustrates me is that when I show them how I work
> and the conclusion I came to using Cooper's methogology, they feel that
> they would have come to the same conclusion with their methodology. They
> see myself as a BA that designs interfaces. They only pay lip service to
> studying goals people have and why they do things but when you look at
> them interview people, they try to hammer these goals out of people's
> mouth by asking 100 times the question "Why". It goes like this :
> - Why do you do this?
> - A
> - Why do you do A
> - B
> - Why do you do B
> and so on for hours.
>
> This is a very lenghty process to try to get at people's goals and they
> can never get to the high level ones. People are not that good at
> introspection. They expect people to tell them everything they need to
> know, like many builders/programmers. When people can't they say that the
> business people are not strong/smart/experienced enough.
>
> In summary, Cooper's methodology is way better at getting WHAT a system
> should do to help people than their methodology and they have no
> methodology to design the HOW a system should do it.
>

Anthropologists know that 'why' is not a good question. People are forced
into a corner and rationalise. 'How' works much better, and generally brings
out the latent whys.

Louise Ferguson
(who pends much of her time on ethnographic research in organisations)

Syndicate content Get the feed