Development vs. Design
In software, design and development are both things I am passionate about;
and have been actively doing for a very long time now. In fact, it should be
said that one cannot exist without the other. Even if you are writing software
with an intended user base of one, you are still going to design the interface
around how you want to use the application. So, it is probably no surprise that
I find it rather troubling that so many businesses still keep these two vital
pieces of their company, so separated. There is a fascinating quote, which I
feel embodies the spirit of my feelings about design and development, from the
book Hagakure:
Our bodies are given life from the midst of nothingness.
Existing where there is nothing is the meaning of the phrase,
“form is emptiness.”
That all things are provided for by nothingness is the meaning of the phrase,
“Emptiness is form.”
One should not think that these are two separate things.
Design is Dead by i-marco
Defective by Design
Unfortunately, businesses tend to continue to put design departments under
the marketing business unit, rather than engineering. I can only imagine that
the common reasoning for this, is that designers make pretty things, and pretty
things are needed to sell products, so therefore designers are marketing.
Unlike the heady days of the early industrial revolution, however, design and
product are now much more tied together than ever before. With the lower
barriers to entry for using both developer tools and graphics design, user
testing, and other design related tools, it's easier than ever for developers
and designers to work together toward the same end. If your business is
maintaining the business unit separation by having design as part of marketing,
it's hurting both teams. Developers no better like having designs thrown at
them, which aren't fully implementable, than designers like being told to make
applications pretty, after they're built and shipped. Good visual design is
important, but being visually different is much less so. Yet, so many companies
strive for the latter as an attempt to achieve the former.
Burning Bridges
The best way to build a new bridge, is to burn down the old one first. If it
doesn't come crashing down, you probably don't need to build anew. If you're a
developer or designer, or have ever seen a thorough discussion betwixt, you can
probably see how those bridges would fall in a blaze of glory. Often, design is
more an afterthought, and developers don't have the time to take the new design
considerations to heart; or the designs lack in what they could change, coming
so late in the game. Sometimes design is a primary thought, done completely
outside the realm of engineering. There is no interaction with the developers
who would be implementing the design, until the majority of the design is
complete. This often leads to software which can't be completed as designed.
The application will sit in a state of limbo, partially complete in both
functionality and design. If your software is to be successful, these bridges
must be burned.
Phoenix by jurvetson
Rising from the Ashes
So the pyres of a thousand bridges are burning in your wake. How do you
build successful applications, and integrate design and development? Many steps
will lead to a better ecosystem for both, but the first thing that needs to
happen is for design to be totally under the engineering unit in a business.
Get your designers and developers sitting next to each other all the time, and
talking about their projects together, on a regular basis. Bring your designers
to development sprints and conferences. Don't bring the whole design team
though, and have them all sit off to the side drawing pretty pictures. Get them
in the middle of core development discussions. If you're a FOSS company,
make sure they are as involved in Community as the developers are. Design is an
engineering resource; consumable by both the software engineer and marketing
resources. Never devote more than 30% of the designers to a single project,
now matter how large the project. If you think it needs more designers, you
need to scale your project back; or you've got way too few designers in the
first place. If you want designers who just do R&D all the time, put them
on an R&D team with a few developers who will also be doing only R&D full time.
Everyone will be happier; designers and developers will both be more
productive. Beyond simply making the design team part of the engineering unit,
there are several additional things you can do, to improve their situation
further:
* Train your designers with basic development principles and tools
- Get them working inside the application's source repo.
- Get them submitting patches/branches to change artwork and text.
- Get them to understand developers don't need a visual design for every little thing
* Train your developers with basic design principles and tools
- Get them to understand the basics of the HIG for the platform their developing against
- Get them in the habit of referring to the HIG for more complex matters
- Get them in the habit of testing for behavior, layout, and other aspects of design
* Train designers and developers to handle Customer Feedback Loop better
- Get developers to understand higher level customer issues with design, beyond crashing
- Get involved and communicate to truly understand where the confusion lies
- Give everyone time to deal with customer issues when planning a project
* Avoid trying to push Visual Design as your Brand
- Visual Different is not always good
- Can lead to sometimes breaking intrinsic features from upstream
- Before changing Visual Design, get everyone involved in understanding why it should change
This is primarily a problem in software, and is where my experience with
these problems lie, but this advice may be applicable to other industries
suffering similar issues, as well.
Syndicated 2010-03-28 20:07:51 from dobey's blog