When to bring in technology

17 Dec 2004 - 9:45am
9 years ago
5 replies
632 reads
Narey, Kevin
2004

>First I want to say, that in general, I totally agree that design and
technology should be separated >as much as possible.....

I'm interested at what point in the process we should make a decision on
what technology should be used. Sure there's a big "it depends", but
generally there is a hiatus point in the process where design cannot
continue unless technology constraints are considered.

I've encountered this as a real problem in the past when
consultants/customers/analysts/Project Managers make rash decisions on
technology based on nothing more than a whim. Sadly this has had dire
consequences.

I'll open the bidding at the "Is this a technological solution?" point of
the process i.e. very close to the beginning of a consulting engagement.

For instance, a call centre MD wants to become more efficient. First
thoughts laed to "outsource the call centre completely" or "examine
processes/users/context for improvement potential with an eye on a tech
solution".

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Comments

17 Dec 2004 - 12:33pm
Listera
2004

Narey, Kevin:

> there is a hiatus point in the process where design cannot
> continue unless technology constraints are considered.

Which is why it's supremely important that designers be knowledgeable about
the technical ramifications of their design choices. IOW, technology
constraints should be considered (by designers) at every step as second
nature, not as a separate task and never as determinants of the process.

When I design or redesign an app, I talk to the tech people at the very
beginning, totally in the abstract without any plans on product, interface,
etc. It's a) to find out what they have and b) to gauge their technical
savvy, risk averseness, etc. The next time the tech people see me is when I
have specific capability issues narrowly defined or most likely when I'm
done with the prototype.

Now, there's also a class of projects where, for variety of reasons, legacy
issues completely dominate everything else so one needs to be very close to
tech constraints. But those are like drinking the pink medicine that tastes
god awful, making you wonder if the designers of that stuff are from this
planet and why it's best just not to get sick to begin with.

One of the better consequences of tech offshoring is that the legacy excuses
("We can't do that") is no longer so valid, discounting the dominance of
technology in design.

Ziya
Nullius in Verba

18 Dec 2004 - 5:27am
kjnarey
2004

Ziya

>.... discounting the dominance of technology in design.

I agree with this sentiment on the whole, but not with the language you've
used. A balance between technology, design for humans and business needs is
emerging - not necessarily the discounting of technology dominance in
design. This is a common cycle in the evolution of global markets gone by.

I read a couple of Martin Fowler's (prominent author of a number of Object
Oriented Programming/UML texts) articles this week and discovered an
interesting development in his thinking.

In 1999 he wrote an article on "Is there such a thing as Object Oriented
Analysis?" which states:

"To argue that one [modelling] language is more natural than another is to
argue that a wooden bridge is more natural than a steel bridge. Either way,
it's a bridge, and it's constructed, not natural."
http://martinfowler.com/distributedComputing/analysis.pdf

Interesting that this example implies that it doesn't matter who or what
uses the bridge as long as it's built. Sound familiar?

In Aug 2003 he wrote a blog entry on using the Building Architect as a
metaphor.

"A software architect is seen as a chief designer, someone who pulls
together everything on the project......Given the focus on client
interaction I think the closest equivalent in software development is a
user-interface designer."
http://martinfowler.com/bliki/BuildingArchitect.html (I like this metaphor
actually, but it's a separate discussion.)

Sure, they are two separate content subjects, but I hope to illustrate the
shift in mindset. It shows that there is a growing realisation not only by
business, but by respected technologists too, for a more people focussed
approach to the design of software, in concert with technologists.

Kevin

18 Dec 2004 - 12:54pm
Listera
2004

kjnarey:

> "A software architect is seen as a chief designer, someone who pulls
> together everything on the project......Given the focus on client
> interaction I think the closest equivalent in software development is a
> user-interface designer."

Been reading Fowler for about a decade now, on patterns, refactoring, XP,
etc. and I often assume the title "application architect" on many projects
myself as well.

There's clearly an overlap. But divergence also. App architects come almost
always from the programming side and are weak on visual/experience end of
things and are mostly system-oriented. A phrase I like to quote from Fowler
is:

"The danger of intermingling design with programming is that programming can
happen without design"

Incidentally, the Cocoa programming environment in Mac OS X,
InterfaceBuilder specifically, has for over a decade been encouraging
interface/interaction design as the starting point of application creation.
IB allows one to prototype without generating code. Here's an old but
succinct overview:

Freeze Dried Objects
<http://www.stepwise.com/Articles/Technical/FreezeDriedObjects.html>

Anyhow, I think we're transgressing the focus/borders of this group.

Ziya
Nullius in Verba

18 Dec 2004 - 1:03pm
Dave Malouf
2005

> Anyhow, I think we're transgressing the focus/borders of this group.

I like living on the blurry edges. When we are talking about how we can best
communicate and work with engineers so that our designs become manifest then
I think we are on ok ground. If we start talking about how to do programming
then we are beyond our borders.

I think this thread has been useful, I know to me, so maybe to others as
well.

What I appreciate about this thread more than anything is that to be a part
of the whole process you can't be a black-box where requirements get input
to, and then design gets output from. Communication is key and finding the
right tools and methods to do that communicating is at the core of all this.
The Question of when to bring in "technology" to me is part of the methods
part and part of the opening the "blackbox".

-- dave

19 Dec 2004 - 10:40am
Rick Cecil
2004

> I'm interested at what point in the process we should make a decision on
> what technology should be used. Sure there's a big "it depends", but
> generally there is a hiatus point in the process where design cannot
> continue unless technology constraints are considered.

Our process has worked quite well. We have an interaction designer and
information architect conduct user interviews (we prefer contextual
inquiry, but are sometimes limited to phone conversations due to
budget constraints) and competitive analysis. From there, we develop
and scenarios. From the scenarios, we can extrapolate the features our
users will want/need/use.

With the feature list in hand, we meet with the Tech Lead and Business
Analyst to review the proposed features. We're not looking for
feedback on feasibility or budgetary constraints at this point--we
just want to communicate the purpose and need for each feature.

The Tech Lead takes the feature list back for review as does the
Business Analyst. The BA examines the features that are important to
the business, and the Tech Lead reviews the features that are easiest
to implement. Meanwhile, the IxD and IA are busy prioritizing the
features based on user wants/needs.

During this prioritization phase, the Tech Lead should be consulting
with his team to best determine what technology should be used or how
best to extend an existing technology.

Once everyone is finished, we meet and compare our prioritizations.
There is a lot of negotiation during this review process--and even
some heated arguments, but it works because everyone is involved in
the planning process. You virtually eliminate project sabotage from
the tech side and are able to generate management buy-in.

HTH,
Rick

Syndicate content Get the feed