Designers are from Venus - Presentationas Given to CD2
1. Developers are from Mars,
Designers are from Venus.
Chad Udell
cd2ug - meeting September 3, 2008
2. A little context
I’m a Designer
I love design, i studied it in school. I have a degree in design and art history. I have my favorite designers, my favorite
web safe hex colors, my favorite pantones. I have designed record cover art, T-shirts, posters, web sites, game
interfaces.
3. A little context
I’m a Developer
I’ve written code. Apps, games, websites, cms, crm, custom stuff, flash, flex, ajax, stuff.
4. What’s the difference?
Some generalizations.
What good is a soap box without a sweeping hyperbole or two? Right?
5. What’s the difference?
Developers are killjoys, squashing
creativity to make a deadline or taking
the easy way out to build functionality.
developers are task oriented. goals and milestones are their lives.
6. What’s the difference?
Designers are fun but reckless, they
create great work but aren’t
concerned with the bottom line.
designers tend to be highly iterative. they use revisions to allow their ideas to grow and shift. they often need
‘inspiration’ or a mood to produce what i lovingly coined ‘design whoo hah’
7. What’s the difference?
A little reality, please.
While each may contain a grain of truth,
both are way off.
Neither of these are true. Obviously designers like to work on profitable projects that launch on time and developers
enjoy creating groundbreaking well designed projects. Where does that lead us?
8. We Need Both
We are on a team, right?
Work habits and
communication styles need to
be standardized to succeed.
The sooner that your team members get that and can move on it, the quicker you can succeed.
9. Changes are Needed
Designers need to be
practical and able to move on
when the goals are achieved.
You must remember the
scope of the project.
Pay attention to your estimates. Pay attention to your hours logged. Be able to end a design cycle and work through
the remaining design issues so you can stay on target. Developer’s use a mantra of “Release Early, Release Often”...
how can you use this mantra as a designer? Paying mind to component based design parameters may help you here. I
recommend designers read a “Pragmatic Programmer” series book or two and possibly “Getting Real” by 37 Signals.
10. Changes are Needed
Developers need to realize
that design does matter.
Ideas need to be able to
mature.
Simply because you have wireframes or block diagrams that are ‘approved’ by the client doesn’t mean they are final.
Some metaphors may just not work when realized into prototyped. Be ready to adjust. Agile methods can aid you
here. Think of a design as the ultimate form of “Extreme Programming”... until the pixels meet your retinas for the
last time, the design can change. Get used to it. Read “Design of Everyday Things” by Donald Norman for a little
insight.
11. Integration Points
Process, Process, Process
“4D’s” of Iona Group
What works for your company?
This is a big topic... Where do your teams match up? Where do things get handed off from one team to another? How
do you interface with each other? Who rules the project’s server?
12. Integration Points
Workflow?
Who is in on that first meeting?
Which team is serving which on this project?
So, do wireframes get created by the developers? Or the Designers? Are the developers creative enough? Are
designers aware of the toolset enough to make intelligent UI choices? Does the lead developer lead the effort or is it
the CD? let the project dictate this. Is it a branding exercise with a little interactivity/application functionality? Or is it
a true deep RIA with little need for “aesthetic” design and a lot of need of functional UI design?
13. Integration Points
File Organization
Directory Structure is Not a Battlefield!
Who rules the project’s server? A thought: Maybe you can organize your folder structure based on your process?
Define, Design, Develop, Deliver works for us. Keep people’s names out of directories. It lacks historical importance
and breeds blame in the short term.
14. Integration Points
Naming
“blue mockup 8 14 08.psd” or “mock1.psd”
what will mean more when the project is complete?
visualrinse.com/2007/06/12/deep-thoughts-on-file-naming-conventions/
What’s in a name? A freaking lot. Designers favor real world words. Fun words. “blue first mockup 8 14 08.psd”
designer’s favor tight short names... “mock1_81408.psd” my tips... eliminate spaces and odd characters. use v2, v3,
r2, r3 to denote version and revision info. See my post “http://visualrinse.com/2007/06/12/deep-thoughts-on-file-
naming-conventions/”
15. Integration Points
Versioning SVN=OMG!
Subversion, CVS are good but can be tough to use for
designers and aren’t really suited for PSD or other binary files.
Version Cue from Adobe is nice, but can be tough to set up
in a bigger workgroup.
Some other options... Unfuddle for SaaS SVN, Warehouse for
an easy to use Web SVN, and Versions for Mac. The upcoming
“Flow” looks great.
Design and Develop teams may go head to head on this often. Developers live in SVN, CVS, SourceSafe, etc...
Designers rely on file structure... my main tip... no “mockup_v3_final.psd”, “mockup_v3_final_final.psd”
16. Integration Points
Taxonomy
Standardize the way you talk about things!
http://edweb.sdsu.edu/courses/et650_online/mapps/Glossary.html
Are they wireframes or block diagrams?
Mockups or Comps?
Don’t get overly jargon-y or use it as a weapon. TLA
dueling and art history barbs just lead to animosity.
As a designer you can flip flop between calling it gutter and margin, leading and line height, tracking and letter
spacing... when you are talking with people that only use those terms occasionally, use the same term each time.
17. Moving Forward
Development 101
Designers, realize that Graphic Design will not save you!
Change the toolset to meet development specs.
When things are slow, opt to take on some typically
“developer” tasks.
Designers with great color sense and excellent use of typography are ahead of developers when it comes to aesthetic,
but what about usability? Interaction design? Data design? I recommend picking up “Designing Interfaces” by Jennifer
Tidwell for a little insight on UI design patterns...Understanding Functionality, Data Follows Function, Form Follows Function, Design
Patterns, A Bit of Needed Tech Jargon for Designers
18. Moving Forward
Design 101
Developers, no one likes programmer art!
Use palettes from sites like Kuler or ColourLovers to
avoid eyesores.
Skins and themes for your apps are out there. Check
out Scalenine.com for some great Flex themes.
There are rapid prototyping tools out there that will help you make good design decisions. Also, if your designer
friends can help you out by providing basic guidelines you should follow for a specific project, great. When Developers
run the design end of a project or are in charge of making UI pattern choices, the user often pays the price with poor usability or
marginal aesthetics. With a few key concepts under their belt, the dreaded “programmer art” syndrome can be avoided.
19. Changing your Process
Teamwork FTW!
Parallel Design and Development Tracks
Rapid App Development (Blend, Thermo)
Proximity matters
Are there ways to do a roundtrip design/dev cycle? How about adopting agile like methods for your design process?
New tools are coming out and maturing on various RIA fronts to help this, but a tool is still only a tool. ... How close
are you to your counterparts? Can you talk in a office level volume and have them hear you?
20. Changing your Process
Tech to try
Let your designers help with XML (yes, even designing schema)
Have your Devs prep some graphics and maybe even do some
skin design from time to time
Does your toolset allow for component creation?
Teach your designers how they work!
When you have time in your workload, why not have designers and devs trade off a bit? Living in each other’s shoes a
bit is a good way to cross train and will at least breed some empathy. Wearing more than one hat can be a productivity
booster for a team and can serve to strengthen a teams understanding of the talent and value the other ones bring to the table.
We have found it valuable when schedule and budget allow, it is a great idea to allow people to stretch their skills a bit and dust
off some tools they might not frequently work in. Think of it as a training wheels approach.
21. Changing your Process
Presentation and Pitching
Unified front!
Who leads? Who follows?
Before the work is even won, it’s important to show a strong united front to a client and to use each team’s strengths to their advantage.
After the contract is signed and work is under way, a team designee from each side should be appointed as a liaison to work with the
Project manager when presenting work to the client. These presentations should be worked through with each team liaison prior to the
client meeting to again give a united front for the client.
22. Growing Forward
How do you keep the afterglow?
Lunch and Learns
Barcamps
Sharing “AHA”s via a team blog
Continued development and grooming of the team dynamics are needed if the integrated approach is to take hold. Often, designers
are not aware of new technologies in the development arena and vice versa. Little gotchas and tool tips are also great to share over a
team lunch. When more confidence is achieved in the respective alternate roles, cross training can produce stronger, better more
productive teams.
23. Growing Forward
Realizing the benefits
Measuring
End of Project recaps
Keeping up with trends and tech
After moving to such an approach, how will you know you have benefited? Is it simply goodwill amongst team members?
Higher margins on projects? Happier clients? Higher overall billable percentages? When the success is realized and the process
is fully implemented, what additional tools can be used on a fully cross trained team to make the work even stronger?
Advanced tools, techniques and new software will be explored.
