Bridging Between Designers and Developers

Josh Warren-White and William Ramirez, Design Action

Session Description

Poonam and William will share and discuss the Design Action approach to web site design, and talk about their best practices for getting the right web site built.

Session Notes

• Power imbalance with developers being able to fake design but designers can't fake development
• Design Action is 9 people, 5 of which are web focused
• Design Action often work on lots of small projects, all at the same time rather than fewer large projects
  • A strong process is important
• Give a very rough ballpark up front ("but don't hold us to it")
• Establishing very clear roles and responsibilities with the client is really important
  • Content migration, etc.
• Within a non-profit, there is often very different ideas around design
  • This really holds up the process
  • Have a detailed questionnaire has helped
  • Sometimes a facilitated group process has been necessary
• The work that goes into intake a contracts is paid
  • Sometimes the client will back out or disappear. In that case we have a deposit to fall back on
• We get sign-off on wireframes before moving on to later phases
• Working with clients that have well thought out wireframes or information architecture
• For a first round of wireframes, we often site down and think through three drastically different ways that a site could be structured
• Including your developer as early in the process as possible can really save you a lot of time. It's easy for a developer to flag things that are hard to build
  • It's not as much of a problem with the in-house projects, because we are running designs by the developers throughout the whole process
• The issue of building before the design is done
  • Sometimes it can save time in terms of timeline
  • But small design changes can have big impact on functionality
• The kind of jobs that DAC does dictates this process. Since they are so small and urgent and low-budget.
• The development of the content can often take the longest of any part
• Getting the back end set up first, get's the working on the content early and see how the content relates to the entire site
• Doing the mockups ahead of time privileges the developers time. Doing the build first privileges designers time.
• Content development and site structure
  • It can be hard to get an effective site map out of a client
  • Either the client has a clear vision and we can ask them to write it down
  • Or, if there is enough time, we could sit down with a client and help them think through the issues
• What's it like having designers or developers as project managers?
• Ongoing maintenance?
  • The overall work periods are small enough in general that slotting in maintenance time hasn't been a problem
• RD has a help queue where clients can request small changes. Each person rotates through a day on help queue so everybody gets to know different sites
• Having clients involved with bug testing
• How much client interaction happens throughout the process
  • Usually there is a lot of interaction
  • since we usually have the back-end set up early, as they are inputting content they see the site progress
• Working between shops
  • Who is doing the project management
  • Sharing all the comps to the developers from the beginning
  • It's nice as a designer to have control over final CSS
  • Who is doing the themeing
• Issues with how the design appears in the real world

Summary

• Having a developer involved early in the process can save the client a lot of money by getting feedback on what is expensive to build
• With the typical design action client (which is usually small, politically urgent, and low-budget), having the back-end set up early can help the client get content in as soon as possible which is often a hold-up
• Working between shops: it's important to be clear about project management
• Designers want to know what things are complicated
• Developers want to know what happens when you resize your window