user centered design -> overlapping circles -> boundary selection

3 Oct 2006 - 4:15pm
8 years ago
3 replies
725 reads
Eugene Chen
2004

I'm working on some product strategy at the moment.

Imagine a scenario like this:
- Book publishers need a system that lets them communicate with the
Warehouse and Authors.
- The Warehouse needs a system that lets them communicate with Publishers,
but they also have need a system to communicate with Stores and manage
Inventory, etc.

If you build the system for the Publishers, then the Warehouse now has to
use two systems, which inevitably are going to have a lot of overlapping
fields.

To put it abstractly,
- User A sits at the center of a circle of concerns that includes User B
- User B sits at the center of a different circle, but theirs also includes
User A

The product starts out being designed for User A, but it doesn't seem fair
in a way to ask or require User B to use this system that then is not a
complete picture for them.
Adding the features for B for the system intended for A seems like a
slippery slope.

The question is: on what principles to base the products boundaries?
Strategically this leads to a question of which systems to compete with
(subsume) vs. interface. And if to interace, then whether communication
should be one-way or two-way?

Thoughts?

Eugene

Eugene Chen | User Experience Research, Design, and Strategy
mobile 415 336 1783 | fax 240 282 7452
web http://www.eugenechendesign.com | aim peastulip | skype eugene-chen

Comments

3 Oct 2006 - 9:00pm
Steve Baty
2009

Eugene,

In general I would be looking for ways to loosely couple the system used by
User B to the one you're designing for User A, so that User A is given
access to the information they need to perform their task effectively. I
would define the integration of the two systems as a separate, but
prequisite requirement of the system you're designing, so that it can be
allocated a separate budget if necessary.

I would also start thinking of the totality of information flows, rather
than disparate systems. You can readily demonstrate the need for the
integration of the two systems through the task requirements for your target
user (at least you should be able to demonstrate), but that doesn't mean
User B now needs to become an active user of your new system. Leave them in
their own environment, but ensure the flow of information isn't stopped at
the boundary of User B's existing systems.

Grab a business analyst and have them map out the data fields that you need
shared between systems, and whether the form of that data in its current
state is suitable for your needs. If not suitable, look first and
transforming the structure of the data in some pre-defined, automated way.
If that's not possible, then you need to start looking at the relative
cost/benefit of having User B operate in both systems; or User A not being
able to perform some subset of their required tasks.

If the data/information created by User A is necessary for User B to perform
some aspect of their role, then, again, look at passing that information
back into their current system. If you're creating new tasks for User B to
perform, then a broader approach to the integration may be required, wherein
you are designing modular additions to the system already in use.

I hope that helps

Steve Baty

On 04/10/06, Eugene Chen <eugene at eugenechendesign.com> wrote:
>
>
>
> The question is: on what principles to base the products boundaries?
> Strategically this leads to a question of which systems to compete with
> (subsume) vs. interface. And if to interace, then whether communication
> should be one-way or two-way?

________________________________________________________________
> 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
>

--
----------------------------------------------
Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
Director, User Experience Strategy
Red Square
P: +612 8289 4930
M: +61 417 061 292

Member, UPA - www.upassoc.org
Member, IxDA - www.ixda.org
Member, Web Standards Group - www.webstandardsgroup.org

4 Oct 2006 - 3:38pm
Mauro Cavalletti
2005

Eugene,

This soubnds correct to me. You might need one *system* and two different
*interfaces*, one for the publishers and one for the warehouse. A single
back-end and two slightly different front-ends. Does it make sense?

If I understand your design challenge, what really matters is sharing the
same database that can manage inputs from diverse sources, and them present
that data arranged propperly to the specific audience. You can take a
systematic approach that provides some level of standardization to the
presentation layer in the two interfaces, meaning you can re-use elements of
your layout or even complete templates, as the structure is somehow similar
and the data is basically the same.

Mauro

Mauro Cavalletti
Creative Director
Organic, Inc.
San Francisco
(415) 581 5346
www.organic.com

>From: Liya Zheng <lzheng at liquidnet.com>
>To: 'Eugene Chen'
><eugene at eugenechendesign.com>,discuss at lists.interactiondesigners.com
>Subject: Re: [IxDA Discuss] user centered design -> overlapping circles
>-> boundary selection
>Date: Wed, 4 Oct 2006 13:44:30 -0400
>
>[Please voluntarily trim replies to include only relevant quoted material.]
>
>Eugene,
>
>Do you think maybe you have one system that contains two different
>interfaces to serve the roles you've described?
>
>It sounds to me that building one interface to serve all the user groups,
>might make it harder for everyone to use it, and maintenance issues will
>arise in the future.
>
>Do you have the time and budget to do some user research so you can model
>your users (maybe in forms of personas)? An exercise like that may help you
>answer the question above and also helps you design a modular product that
>is easier to maintain.
>
>Good luck! Sounds like a fun and challenging project.
>
>Liya
>
>
>-----Original Message-----
>From: discuss-bounces at lists.interactiondesigners.com
>[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Eugene
>Chen
>Sent: Tuesday, October 03, 2006 6:15 PM
>To: discuss at lists.interactiondesigners.com
>Subject: [IxDA Discuss] user centered design -> overlapping circles ->
>boundary selection
>
>[Please voluntarily trim replies to include only relevant quoted material.]
>
>I'm working on some product strategy at the moment.
>
>Imagine a scenario like this:
>- Book publishers need a system that lets them communicate with the
>Warehouse and Authors.
>- The Warehouse needs a system that lets them communicate with Publishers,
>but they also have need a system to communicate with Stores and manage
>Inventory, etc.
>
>If you build the system for the Publishers, then the Warehouse now has to
>use two systems, which inevitably are going to have a lot of overlapping
>fields.
>
>To put it abstractly,
>- User A sits at the center of a circle of concerns that includes User B
>- User B sits at the center of a different circle, but theirs also includes
>User A
>
>The product starts out being designed for User A, but it doesn't seem fair
>in a way to ask or require User B to use this system that then is not a
>complete picture for them.
>Adding the features for B for the system intended for A seems like a
>slippery slope.
>
>
>The question is: on what principles to base the products boundaries?
>Strategically this leads to a question of which systems to compete with
>(subsume) vs. interface. And if to interace, then whether communication
>should be one-way or two-way?
>
>Thoughts?
>
>Eugene
>
>
>
>Eugene Chen | User Experience Research, Design, and Strategy mobile 415
>336 1783 | fax 240 282 7452 web http://www.eugenechendesign.com | aim
>peastulip | skype eugene-chen
>
>________________________________________________________________
>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

4 Oct 2006 - 4:56pm
Dave Malouf
2005

3 Letters sorta say it all for me when you have a problem like this one.

A-P-I

"Application Program Interface"

Well, to be more specific, I think that people have the right intentions
with the "2 interface" solution, but having spent the last 6 years doing
enterprise software it is almost impossible for one end of the supply-chain
to force another end of the supply chain to use the same tools. Obvious
exceptions are Wal-Mart. Bur for us mere mortals the best we can really hope
for is to create the right "on-ramps" and "off-ramps" for the correctly
mapped data structures.

Good luck!

-- dave

Syndicate content Get the feed