Designers Talking to Developers 2012

Facilitated by Sabiha Basrai and Sarah Reilly

Design Action Collective members will present a case study on successful collaborations between graphic designer and developer when working with social justice organizations, followed by a group discussion on roles and responsibilities. Come share challenges and lessons learned as we help each other build better practices around graphic design and development.

Go Around: Why are we here?

• making design and dev collaboration work
• developers working with designers remotely, communication can be difficult
• developer working in a shop that doesn't have designers in house, often working with new designers chosen by clients, hard to figure out consistent and effective workflows
• designer looking to communicate with developers better
• development starting before design--how to navigate it, or is it just a bad idea generally?

Design Action Collective

• DAC: ~10 folks, dedicated to providing communication tools to the social justice movement & serve movement needs.
• started around 10 years ago with 2 folks; worker-owned coop, unionized, and have shared points of political unity that help determine what projects to take on
• design for social justice is countering corporate design & messaging; our stories are coopted and sold back to us; when our stories are captured, they're often stripped of the larger movements and brought down to solitary individuals
• countering that is a driving principle of DAC
• started as a print shop, moved in to web dev, have had to develop a process of communication to bring their design to the web effectively
• focus on communication between developers, designers, and the client
• intentionally developed DAC as a graphic design shop that also develops in other media
• designers had to learn that web is a very different medium from print; also a shop that works with outside developers

Case Study

• project that Sarah and Sabiha worked on together; Sabiha has a graphic design background, Sarah has WP/Joomla dev background
• Urgent Action Fund for Women's Human Rights: longtime client, worked with DAC on print before working on them with web
• organization that serves women in conflict situations, critical situations, give grants with rapid turnaround, rapid response grantmaker that's uniquely accessible internationally
• DAC helped them define their brand so the urgentness came through; also visualizing the women who were involved on the ground leading the priorities of the organization
• Web design: bring that entire story while considering the capabilities and limitations of the website platform
• Took them through information architecture process, a many hour phone call to determine entire IA and site structure
• two primary target audiences: donors (rich imagery in appeals, lots of textures) and grantees (a lightweight, very accessible site for quick easy access with limited bandwidth, language & translation consideration). Dual audiences meant compromises, keep site light and accessible while still retaining the brand that had been developed in print design.
• This was a three-way conversation between the developer, designer, and the client
• Having the conversations while the UAF staff was looking at wireframes made those decisions real
• Designer was part of all of the conversations; Sabiha knew the challenges that were being faced by the client, by Sarah as the developer, and also was familiar with the longstanding development of the brand
• Sabiha and Sarah checked in with each other through every step about the considerations and compromises
• Started design process by showing a variety of design options, starting from very lightweight but less rich imagery and textures to a more developed, rich, textured but heavy design, things that were difficult to tile and could be hard on low bandwidth connections
• UAF was leaning towards the heaviest design that really represented their brand; Sarah and Sabiha had to communicate a lot around meeting that client desire while still keeping the constraints in mind.
• UAF decided to go with slower download time for the benefit of reinforcing their brand
• As a failsafe, DAC added a button at the top corner that strips out the stylesheet and allows a site visitor to view all the text content. A compromise, not the best for the site visitors, but still makes the information accessible at very limited bandwidth

Discussion

• (fill in notes about DAC/Palante collaboration on CPR)
• Sabiha: as a designer it's very important to understand or contribute to the information architecture, how content flows visually; then there's no suprirses in the design or impleentation phases because those decisions have been made collaboratively. If there's been a half-assed IA process and new elements are introduced down the road, that can be tricky. It's necessry to manage expectations around the roles of designers and developers, plus the clients' planning. When a developer is just given a completed design, if the IA was in place already, that could work.
• Question: what does it matter? There's personal or professional discomfort--is it personal discomfort or is it project impact? There can be a financial impact, and there can be a professional/interpersonal impact.
• For DAC, the metrics are always a) what are the goals of the project and b) is the process meeting those goals?
• Effective technical good is a very subjective issue; the idea of understanding whether something has hit the goal is very subjective.
• Projects are so fluid and atomized; what does it matter if things get messed up?
• If you set up client expectations at the beginning, you can have successful collaborations.
• Clients need internal processes around figuring out internal needs.
• One approach: having a product owner within the client organization, make the decisions and communicate; the internal organizational process can be whatever they want, but having one person empowered to sign off is important.
• There's the point person, but there's also the need to communicate to the clients that we can't start any of the work until many questions are answers. What is the organization trying to do, what are your audiences, timeline goals, how are you perceived, how do you want to be perceived, what's the capacity on the team for doing the updates. Answering all of those questions first before starting with information architecture or design is very important. Oftentimes DAC needs to ask the client to figure out the questions internally, can even help facilitate that; lots of times organizations realize what they really need is not a product (website, logo) but an opportunity to retreat and define goals and needs. Having those questions answered makes the expectations real and solidifies trust between client and designer/developers.
• Goal is to advance social justice; we want to figure out a process that will yield that success.
• (fill in notes about the closed process, being stuck with design things that go against web standards, etc)
• Important to talk to clients about web standards, responsive design, etc from the start, but also to ground it in social justice/organizational principles, e.g. that web standards will make the site more accessible and allow the organization to better reach their constituencies and target audiences.
• A good conversation to have with the client is to say that we don't want you to run out of money, highlight issues and problems, in the interest of the client.
• Waste is never good; approaching money and budgets is grounded in being on the same team, working towards joint goals, wanting the project to be as successful as possible.
• Question: what has been most successful in terms of individual blocks of content; how does the process of getting that from the client work, what do you ask for when? As a dev, run into situations where there was dissonance between the designer, developer, and content developer about how things worked. E.g. a beautiful layout but the client wanted to be more verbose; since there wasn't open communication, there wasn't the ability to talk between the client, designer, and developer to figure out how to make it work. Dissonance between content realities and design/development.
• Approach: get it real ASAP, real labels and real text, cram it all together; it's crappy in its initial form, but it's easier to fix and work with.
• Sarah: as a dev, since it's easy to talk to the designers directly, it's easy to communicate directly and figure out how to modify or revisit the design in response to evolving realities around content and functionality.
• In the IA process, DAC determines the type of content, but the actual content comes later. Clients do most of the content entry themselves so they don't have to pay someone to do that.
• Having content during the site mapping process--what kind of content, how much--is really helpful. Having that discussed early is important, even examples of what the information could be, draft content. A stack of the sort of stuff a client wants on the site.
• The more that you can get a sense of the culture of the team that's giving you info, the less headaches you'll have and the more you can assess your needs.
• Design needs to be flexible, design the basic ideas and essences and work with the client to develop in detail. Have a back and forth with the client without getting ahead of them.
• Do clients push back against all the process and ask to just start building? How do you deal with that?
• Sabiha: have declined to take on projects because of that sort of pushback.
• Sarah: DAC starts out with some discovery before even taking on the project, but are up front about the need for planning before process. DAC does respond to RFPs, but some of them have a decent amount of details about what's needed.
• Even when clients understand that there will be some work on their end, they might not understand the amount of collaboration that can be necessary. It can take months. If they come with a timeline that's unreasonable, then we can say no to projects like that. There's different gauges that we can use to make those decisions.
• Painful process when a client is having conflicting branding issues, but also wants to dictate a design without a process.
• Encouraging a product owner is good for the culture of nonprofits; it provides validation for making decisions, facilitating collaboration, being an actor in a tech project.
• Question: how do folks deal with situations where the point person/product owner for a client leaves partway through or at the end of a project?
• Lots of DAC folks have worked at nonprofits before coming to DAC, so understand the dynamics of leadership, decision making and accountability that can exist there; what DAc defines as success is being able to measure goals, come at the work with a feeling of trust; that if everyone is coming to the process from a point of trust, understanding, open communication, things can go a lot more smoothly. Everyone who needs to be is kept in the loop.
• Internally the point people for clients need to be on top of sharing the information with folks who are coming in afterward if they're leaving. The mutual trust is very important.