https://devsummit.aspirationtech.org/index.php?title=Bridging_Between_Designers_and_Developers&feed=atom&action=historyBridging Between Designers and Developers - Revision history2024-03-29T09:20:07ZRevision history for this page on the wikiMediaWiki 1.35.1https://devsummit.aspirationtech.org/index.php?title=Bridging_Between_Designers_and_Developers&diff=593&oldid=prevVivian: 1 revision imported2015-05-05T18:48:15Z<p>1 revision imported</p>
<p><b>New page</b></p><div>Josh Warren-White and William Ramirez, Design Action<br />
= Session Description =<br />
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.<br />
<br />
= Session Notes =<br />
<br />
* Power imbalance with developers being able to fake design but designers can't fake development<br />
* Design Action is 9 people, 5 of which are web focused<br />
* Design Action often work on lots of small projects, all at the same time rather than fewer large projects<br />
** A strong process is important<br />
* Give a very rough ballpark up front ("but don't hold us to it")<br />
* Establishing very clear roles and responsibilities with the client is really important<br />
** Content migration, etc.<br />
* Within a non-profit, there is often very different ideas around design<br />
** This really holds up the process<br />
** Have a detailed questionnaire has helped<br />
** Sometimes a facilitated group process has been necessary<br />
* The work that goes into intake a contracts is paid<br />
** Sometimes the client will back out or disappear. In that case we have a deposit to fall back on<br />
* We get sign-off on wireframes before moving on to later phases<br />
* Working with clients that have well thought out wireframes or information architecture<br />
* For a first round of wireframes, we often site down and think through three drastically different ways that a site could be structured<br />
* 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<br />
** 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<br />
* The issue of building before the design is done<br />
** Sometimes it can save time in terms of timeline<br />
** But small design changes can have big impact on functionality<br />
* The kind of jobs that DAC does dictates this process. Since they are so small and urgent and low-budget.<br />
* The development of the content can often take the longest of any part<br />
* 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<br />
* Doing the mockups ahead of time privileges the developers time. Doing the build first privileges designers time.<br />
* Content development and site structure<br />
** It can be hard to get an effective site map out of a client<br />
** Either the client has a clear vision and we can ask them to write it down<br />
** Or, if there is enough time, we could sit down with a client and help them think through the issues<br />
* What's it like having designers or developers as project managers?<br />
* Ongoing maintenance?<br />
** The overall work periods are small enough in general that slotting in maintenance time hasn't been a problem<br />
* 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<br />
* Having clients involved with bug testing<br />
* How much client interaction happens throughout the process<br />
** Usually there is a lot of interaction<br />
** since we usually have the back-end set up early, as they are inputting content they see the site progress<br />
* Working between shops<br />
** Who is doing the project management<br />
** Sharing all the comps to the developers from the beginning<br />
** It's nice as a designer to have control over final CSS<br />
** Who is doing the themeing<br />
* Issues with how the design appears in the real world<br />
<br />
<br />
<br />
<br />
== Summary ==<br />
<br />
* 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<br />
* 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<br />
* Working between shops: it's important to be clear about project management<br />
* Designers want to know what things are complicated<br />
* Developers want to know what happens when you resize your window</div>Vivian