Designers are from Venus - Presentationas Given to CD2
0 likes704 views
1. The presentation notes differences in how developers and designers work, such as developers focusing on tasks/milestones while designers iterate ideas, but argues neither stereotype is fully true. 2. It recommends standardizing processes, communication, and file organization to facilitate teamwork. Designers should consider usability and developers should value design. 3. Changing work habits could include designers learning development skills and developers taking on graphic design tasks occasionally to gain perspective. Teams should communicate closely and present a unified front to clients.
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.
- 24. Following Up visualrinse.com This presentation for download Reading list More posts on this topic - category: “ria”