Communicating Design/ Deliverables

17 Jan 2007 - 3:29pm
7 years ago
19 replies
1184 reads
Vishal Subraman...
2005

How do those of you who don't actually write code that is eventually used in
the build (both front-end and back-end) communicate your designs and
interaction models?

Here are two possible options-

1. Static mocks (accompanied with documentation for details)
2. Interactive mocks- HTML/JS, Flash, Prototyping tools like Axure (with
little or no documentation- most interactivity defined by prototype)

We currently use static mocks as a part of the design document, behavior
described in tables adjacent to the mocks. The document tends to
become voluminous, but the websites are large and details are necessary lest
the developers build something that was not intended. We recently started
using interactive prototypes for some smaller projects (used all 3 tools
mentioned above), but I'm not certain they will scale well for larger
projects (in terms of efficiency). In an earlier discussion on prototyping
tools, I remember someone mentioning that while creating prototypes, our
energy is spent 'fudging with the tool' as opposed to focussing on designing
the best experiences & interaction models.

What are your experiences? Pros and Cons of either option...Any option I
might have missed?

-Vishal

Comments

17 Jan 2007 - 3:52pm
.pauric
2006

There is a third option if you find yourself dealing with multiple dev
teams: own the presentation layer

I started with the static wireframes generated in visio (I now use omni)
worked with engineering, after the project I was able to extract the html/js
and use it as part of the spec going forward.

In my situation I need to not only communicate the design but also the
process. But, the ultimate advantages are
control of the presentation layer
reduced development time
reduced testing

New designs are wireframed > agreed > coded and then rolled back in to the
shelf

Here's a screen grab of my intranet portal which combine an explanation of
the process for the other wannabe dictators (o; as well as links to the
various mockups and specifications.
http://web.mac.com/pauric_ocallaghan/web_design_process.jpg

regards - pauric
--
Job type: In house
Field: Embedded & physical interfaces. Web/cli

17 Jan 2007 - 4:40pm
Vishal Subraman...
2005

That might work well for smaller teams/project...but our teams are typically
>30 (and this is only product team) and front-end developers have to work
with many factors like creating custom style sheets for the CMS, developing
stuff in Tcl etc... the whole nine yards in an enterprise environment. It
may not be possible for the design team to own the code. Things were easier
when the dev team was across the aisle. But half way across the world is a
different story.

Has anyone had luck with enterprise tools like iRise/ Serena etc?

-Vishal

On 1/17/07, pauric <radiorental at gmail.com> wrote:
>
> There is a third option if you find yourself dealing with multiple dev
> teams: own the presentation layer
>
> I started with the static wireframes generated in visio (I now use omni)
> worked with engineering, after the project I was able to extract the
> html/js
> and use it as part of the spec going forward.
>
> In my situation I need to not only communicate the design but also the
> process. But, the ultimate advantages are
> control of the presentation layer
> reduced development time
> reduced testing
>
> New designs are wireframed > agreed > coded and then rolled back in to the
> shelf
>
> Here's a screen grab of my intranet portal which combine an explanation of
> the process for the other wannabe dictators (o; as well as links to the
> various mockups and specifications.
> http://web.mac.com/pauric_ocallaghan/web_design_process.jpg
>
> regards - pauric
> --
> Job type: In house
> Field: Embedded & physical interfaces. Web/cli
> ________________________________________________________________
> 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
>

17 Jan 2007 - 5:01pm
.pauric
2006

"It may not be possible for the design team to own the code" if you create
the specification... you effectively control the code. If someone claims it
needs to reside on a server somewhere I'd tell them to wise up. I'm not a
true coder but any designer worth their salt should at least be able to hack
their way through html/js.

To your point on scalability. I am the single embedded UI designer in a
multinational. A little over 3500 engineers in 2 development offices in
China, 1 in India, 1 in the UK, 1 in the US. Also currently driving 4 OEM
vendors, 1 Israel, 1 Germany, 2 Taiwan. I work across 4 product families
and usually have 4-6 projects on the boil. To give you an idea on the
complexity of the products, the average traditional webspec (wireframe
images & table of controls) uses up +300 pages. I could go on, my point is
after doing this for close to 10 years now, that process is the only thing
that keeps the hair on my head... sorry if I seem a defensive about it...
its my 'precious'.

Own the code, trust me.

regards - pauric

--
Job type: In house
Field: Embedded & physical interfaces. Web/cli

17 Jan 2007 - 6:03pm
.pauric
2006

"Own the code" correction.. presentation layer code.

However, if you're constricted to keeping the disconnect between the
output of design and input to development, an overview of the more
advanced ui specification tools can be found here;
http://www.boxesandarrows.com/view/visio_replaceme

17 Jan 2007 - 6:42pm
Josh
2006

"Owning the code" (presentation layer) is good advice if you have little
actual control over what the developers actually build. It can definitely
save time do away with unnecessary killing of trees.

I am curious why you have such a large team and why there seems to be so
much distrust between the product team and the developers? It may not be a
documentation issue but more of a communication/process issue that needs to
be addressed. As far as documentation is concerned, find the best possible
document to convey the message. If the developers don't understand the
interaction points, make a prototype. If the developers can't give you
pixel-perfect designs then give them a styleguide and mock-ups. My ultimate
recommendation is to keep the lines of communication open. Build a
relationship with the people doing the building and get them involved as
early as possible so they're vested in the end result.

Captain Obvious
- Josh Viney

On 1/17/07, pauric <radiorental at gmail.com> wrote:
>
> "Own the code" correction.. presentation layer code.
>
> However, if you're constricted to keeping the disconnect between the
> output of design and input to development, an overview of the more
> advanced ui specification tools can be found here;
> http://www.boxesandarrows.com/view/visio_replaceme
> ________________________________________________________________
> 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
>

18 Jan 2007 - 6:59am
.pauric
2006

"It may not be a documentation issue but more of a
communication/process issue that needs to
be addressed. "

By giving code to engineers I feel some of the communication
limitations, found in traditional documentation, are eliminated.

Also, the process is shorter because dev teams do not need to spend
cycles at the start of a project interpreting docs and checking in
with me. Projects hit the ground running with focus on the new
functionality (wireframed in to the code)

Again, 'owning the presentation layer code' works well when working
with multiple dev teams. This implies you have some commonality
between interfaces, why not reuse those implementations instead of
reinventing the wheel each time? Especially if its a multi
cultural/language environment.

18 Jan 2007 - 10:39am
DrWex
2006

I'm personally in favor of static models. I don't write code (any
more). I could pick a code/language/prototyping tool but then I'd
have to figure out how to integrate that particular system with the
environment at each company. I've found static prototypes to be more
universal (most everyone recognizes paper, Visio, Photoshop, etc) and
quicker to produce in part because there's less environmental 'drag.'
If you're spending your time worrying about what version of TCL/Tk
people have for creating and viewing your prototype then you're not
spending your time creating design products.

I agree that there are issues of ownership and fidelity of the
implemented system to the designed and tested prototype, but I'd
rather work on those issues - which I view as essential parts of
developing the relationship between IxD/HF and development - than futz
with installers, compilers, or debuggers.

18 Jan 2007 - 10:52am
Mark Schraad
2006

Owning the code is so 90's

I will flat out disagree on this issue. Maybe,... maybe if you are a small shop or a one man pperation this works, but the industry has likely moved past you. Granted you need to be aware of the capabilities and some of the inner working in the technology, but if I do not have developers that can write code better than the UI or visual team I have much larger issues. There is too much to know and I want dedicated top level experts working on my projects... not do it all jack of all trades people.

Mark

>"Own the code" correction.. presentation layer code.
>
>However, if you're constricted to keeping the disconnect between the
>output of design and input to development, an overview of the more
>advanced ui specification tools can be found here;
>http://www.boxesandarrows.com/view/visio_replaceme

18 Jan 2007 - 10:59am
.pauric
2006

Vishal: "Pauric- to clarify what you said, did you mean that you/ team first
comes up with static wireframes and then create the front end (html,css, js)
and then hand over the code to the developers?"

I do not do wireframe>html work alone, I work with the developers in a
traditional sense when faced when creating new elements from scratch.

If every project you work on is a completely new design, ignore everything
I've said, its not relevant. But if you are working within a road map or a
product suite with multiple teams, it seems a complete no-brainer to keep
the presentation layer central and maintained by those who define it. It
has proven to be an efficient solution in a distributed development
environment.

And as you noted, not everyone is interested in reading a spec. Having an
interactive mockup as a major part of the specification process makes it
accessible to all stakeholders. So much so that the mockup is well on the
way to becoming a defacto requirement in the product specification process.
However this in itself presents a challenge as you will find a lot more
input from self described UI experts.

Alan "I could pick a code/language/prototyping tool but then I'd have to
figure out how to integrate that particular system with the environment at
each company."

If you're a consultant/contractor then this is true. But if you work for a
company who outsources the work then their underlying framework is
irrelevant. There's a sliding scale of integration. From simply running the
mockup alongside their implementation and replicating the design as I've
found when the vendor used asp .net, through to transplanting the html/js on
to their backend and stitching it together.

Mark "but if I do not have developers that can write code better than the UI
or visual team I have much larger issues."
I never said I wrote code better than a developer. What I am saying is
static images and abstract documents are inefficient in some cases. I fail
to see how taking ownership of the endproduct is 'so 90s'. Welcome to the
21st global economy where your designer can be in Ireland, Program manager
in Santa Clara and development team is split between software from Isreal
and hardware from Taiwan. You telling me a word doc cuts the mustard?

18 Jan 2007 - 11:20am
DrWex
2006

I'm just going to focus on the bit that was addressed to me:

On 1/18/07, pauric <radiorental at gmail.com> wrote:
> Alan "I could pick a code/language/prototyping tool but then I'd have to
> figure out how to integrate that particular system with the environment at
> each company."
>
> If you're a consultant/contractor then this is true. But if you work for a
> company who outsources the work then their underlying framework is
> irrelevant. There's a sliding scale of integration. From simply running the
> mockup alongside their implementation and replicating the design as I've
> found when the vendor used asp .net, through to transplanting the html/js on
> to their backend and stitching it together.

I have worked as a consultant and contractor. But I've also bounced
around companies as an employee. Perhaps that's peculiar to my own
employment history but I do think that IxD people need to think about
how transferrable their skills are.

I confess I do not understand your comments about outsourcing nor
about the sliding scale. I'm sorry.

--Alan

18 Jan 2007 - 1:30pm
Mark Schraad
2006

My mistake Pauric, I thought that when you said "own the code", you actually meant to own the code. If what you meant was to "own the experience" and maintain the standards all the way throught the project... I am totally on board.

Mark

>
>Mark "but if I do not have developers that can write code better than the UI
>or visual team I have much larger issues."
>I never said I wrote code better than a developer. What I am saying is
>static images and abstract documents are inefficient in some cases. I fail
>to see how taking ownership of the endproduct is 'so 90s'. Welcome to the
>21st global economy where your designer can be in Ireland, Program manager
>in Santa Clara and development team is split between software from Isreal
>and hardware from Taiwan. You telling me a word doc cuts the mustard?
>

18 Jan 2007 - 6:17pm
Esteban Barahona
2006

indeed... this cleaner method that you're using leaves less wasted mental
resources in minutae translations.

2007/1/18, Alan Wexelblat <awexelblat en gmail.com>:
>
> I'm personally in favor of static models. I don't write code (any
> more). I could pick a code/language/prototyping tool but then I'd
> have to figure out how to integrate that particular system with the
> environment at each company. I've found static prototypes to be more
> universal (most everyone recognizes paper, Visio, Photoshop, etc) and
> quicker to produce in part because there's less environmental 'drag.'
> If you're spending your time worrying about what version of TCL/Tk
> people have for creating and viewing your prototype then you're not
> spending your time creating design products.
>
> I agree that there are issues of ownership and fidelity of the
> implemented system to the designed and tested prototype, but I'd
> rather work on those issues - which I view as essential parts of
> developing the relationship between IxD/HF and development - than futz
> with installers, compilers, or debuggers.
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss en 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 en ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
http://www.zensui.org

18 Jan 2007 - 6:20pm
Esteban Barahona
2006

2007/1/18, Mark Schraad <mschraad en mac.com>:
>
> (...) but if I do not have developers that can write code better than the
> UI or visual team I have much larger issues. There is too much to know and I
> want dedicated top level experts working on my projects... not do it all
> jack of all trades people.
>
> Mark

What about XHTML/CSS? What about higher level languages? I honestly don't
mind using them, and I don't consider myself a "jack of all trades".

19 Jan 2007 - 9:35am
Vishal Subraman...
2005

>If you're spending your time worrying about what version of TCL/Tk
>people have for creating and viewing your prototype then you're not
>spending your time creating design products.

Funny Alan mentioned this, but our company uses a Tcl based CMS and writing
the markup, css and interactions for it and integrating it with the front
end for the rest of the non-cms content is a full-time job from itself.
Coming from an engineering background, I not only did the Ixd, graphic
design, front-end design for my thesis, but also did the db design and
server side scripting for it.

Guess it also has to do with the way the team is organized. You could have
10 Ixd'ers all of whom work on the front-end code too (which a lot of
companies do) or have 5 people who just do the Ixd and 5 for the front-end
coding. We have the latter (and I like it that way)...more importantly, the
front-end folks are a part of the developemet team and not the design team.
I'm sure this may not work in all cases..different products may require
different setups.

On 1/18/07, Esteban Barahona <esteban.barahona at gmail.com> wrote:
>
> 2007/1/18, Mark Schraad <mschraad at mac.com>:
> >
> > (...) but if I do not have developers that can write code better than
> the
> > UI or visual team I have much larger issues. There is too much to know
> and I
> > want dedicated top level experts working on my projects... not do it all
> > jack of all trades people.
> >
> > Mark
>
>
> What about XHTML/CSS? What about higher level languages? I honestly don't
> mind using them, and I don't consider myself a "jack of all trades".
> ________________________________________________________________
> 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
>

19 Jan 2007 - 9:52am
Vishal Subraman...
2005

edit: Funny Alan mentioned this, because...

On 1/19/07, Vishal Iyer <vishaliyer1 at gmail.com> wrote:
>
> >If you're spending your time worrying about what version of TCL/Tk
> >people have for creating and viewing your prototype then you're not
> >spending your time creating design products.
>
> Funny Alan mentioned this, but our company uses a Tcl based CMS and
> writing the markup, css and interactions for it and integrating it with
> the front end for the rest of the non-cms content is a full-time job from
> itself. Coming from an engineering background, I not only did the Ixd,
> graphic design, front-end design for my thesis, but also did the db design
> and server side scripting for it.
>
> Guess it also has to do with the way the team is organized. You could have
> 10 Ixd'ers all of whom work on the front-end code too (which a lot of
> companies do) or have 5 people who just do the Ixd and 5 for the front-end
> coding. We have the latter (and I like it that way)...more importantly, the
> front-end folks are a part of the developemet team and not the design team.
> I'm sure this may not work in all cases..different products may require
> different setups.
>
>
>
> On 1/18/07, Esteban Barahona <esteban.barahona at gmail.com> wrote:
> >
> > 2007/1/18, Mark Schraad <mschraad at mac.com>:
> > >
> > > (...) but if I do not have developers that can write code better than
> > the
> > > UI or visual team I have much larger issues. There is too much to know
> > and I
> > > want dedicated top level experts working on my projects... not do it
> > all
> > > jack of all trades people.
> > >
> > > Mark
> >
> >
> > What about XHTML/CSS? What about higher level languages? I honestly
> > don't
> > mind using them, and I don't consider myself a "jack of all trades".
> > ________________________________________________________________
> > 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
> >
>
>

19 Jan 2007 - 3:35pm
.pauric
2006

Mark: "If what you meant was to "own the experience" and maintain the
standards all the way throught the project... I am totally on board."

I dont think it is possible to own the experience. That is the domain
of the user, no?

At the core of my way of working is a re-use of library elements in a
way that is practical to both designer and coder. Its not applicable
to everyone and I think I covered where it works. One only has to
look at what the high end prototyping tools try to achieve to see the
issue, i.e. the disconnect, and this is just a way of solving that..
albeit by getting your hands dirty. I hear you on being a jack of all
trades, I view that differently.. I'm communicating design with
developers in their language.

19 Jan 2007 - 4:12pm
Esteban Barahona
2006

Ån IxDer that doesn't know technology is like a katana artisan that doesn't
know its steel. SOFTWARE IS A PRODUCT!!! and a MATERIAL one... quantum
electrons as base modules...

Computers can use

01
@01
0123456789
hex
w-e

2007/1/19, Vishal Iyer <vishaliyer1 en gmail.com>:
>
> >If you're spending your time worrying about what version of TCL/Tk
> >people have for creating and viewing your prototype then you're not
> >spending your time creating design products.
>
> Funny Alan mentioned this, but our company uses a Tcl based CMS and
> writing
> the markup, css and interactions for it and integrating it with the front
> end for the rest of the non-cms content is a full-time job from itself.
> Coming from an engineering background, I not only did the Ixd, graphic
> design, front-end design for my thesis, but also did the db design and
> server side scripting for it.
>
> Guess it also has to do with the way the team is organized. You could have
> 10 Ixd'ers all of whom work on the front-end code too (which a lot of
> companies do) or have 5 people who just do the Ixd and 5 for the front-end
> coding. We have the latter (and I like it that way)...more importantly,
> the
> front-end folks are a part of the developemet team and not the design
> team.
> I'm sure this may not work in all cases..different products may require
> different setups.
>
>
>
> On 1/18/07, Esteban Barahona <esteban.barahona en gmail.com> wrote:
> >
> > 2007/1/18, Mark Schraad <mschraad en mac.com>:
> > >
> > > (...) but if I do not have developers that can write code better than
> > the
> > > UI or visual team I have much larger issues. There is too much to know
> > and I
> > > want dedicated top level experts working on my projects... not do it
> all
> > > jack of all trades people.
> > >
> > > Mark
> >
> >
> > What about XHTML/CSS? What about higher level languages? I honestly
> don't
> > mind using them, and I don't consider myself a "jack of all trades".
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss en 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 en 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 en 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 en ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
http://www.zensui.org

19 Jan 2007 - 4:16pm
Vishal Subraman...
2005

The analogy that works best for me is -

Designers (Ixd, Ux, Visual etc) : Developer :: Architect : Civil Engineer

The architect of course knows the basics of structures and whatever else
that goes into constructing a building. Wanna make him actually build it?

-Vishal

On 1/19/07, Esteban Barahona <esteban.barahona at gmail.com> wrote:
>
> Ån IxDer that doesn't know technology is like a katana artisan that
> doesn't know its steel. SOFTWARE IS A PRODUCT!!! and a MATERIAL one...
> quantum electrons as base modules...
>
> Computers can use
>
> 01
> @01
> 0123456789
> hex
> w-e
>
> 2007/1/19, Vishal Iyer <vishaliyer1 at gmail.com>:
> >
> > >If you're spending your time worrying about what version of TCL/Tk
> > >people have for creating and viewing your prototype then you're not
> > >spending your time creating design products.
> >
> > Funny Alan mentioned this, but our company uses a Tcl based CMS and
> > writing
> > the markup, css and interactions for it and integrating it with the
> > front
> > end for the rest of the non-cms content is a full-time job from itself.
> > Coming from an engineering background, I not only did the Ixd, graphic
> > design, front-end design for my thesis, but also did the db design and
> > server side scripting for it.
> >
> > Guess it also has to do with the way the team is organized. You could
> > have
> > 10 Ixd'ers all of whom work on the front-end code too (which a lot of
> > companies do) or have 5 people who just do the Ixd and 5 for the
> > front-end
> > coding. We have the latter (and I like it that way)...more importantly,
> > the
> > front-end folks are a part of the developemet team and not the design
> > team.
> > I'm sure this may not work in all cases..different products may require
> > different setups.
> >
> >
> >
> > On 1/18/07, Esteban Barahona <esteban.barahona at gmail.com > wrote:
> > >
> > > 2007/1/18, Mark Schraad <mschraad at mac.com>:
> > > >
> > > > (...) but if I do not have developers that can write code better
> > than
> > > the
> > > > UI or visual team I have much larger issues. There is too much to
> > know
> > > and I
> > > > want dedicated top level experts working on my projects... not do it
> > all
> > > > jack of all trades people.
> > > >
> > > > Mark
> > >
> > >
> > > What about XHTML/CSS? What about higher level languages? I honestly
> > don't
> > > mind using them, and I don't consider myself a "jack of all trades".
> > > ________________________________________________________________
> > > 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
> >
>
>
>
> --
> http://www.zensui.org

20 Jan 2007 - 8:36am
Esteban Barahona
2006

2007/1/19, Vishal Iyer <vishaliyer1 en gmail.com>:
>
> The analogy that works best for me is -
>
> Designers (Ixd, Ux, Visual etc) : Developer :: Architect : Civil Engineer
>
> The architect of course knows the basics of structures and whatever else
> that goes into constructing a building. Wanna make him actually build it?
>
> -Vishal
>

Design : Architect : Developer : Engineer

yes... I wanna make him actually build it. thanks btw

--
http://www.zensui.org

Syndicate content Get the feed