Let’s face it, designers love developers. We must-- because without them, our designs would remain a static representation of what could be. But the process of developing a thoughtful user interface from a flat file into a live, responsive, useful means of communicating requires a lot of... communicating! There are many different ways to tell your developer(s) how you (and your client) want each element of the design to look and behave. Here are some tips that will help with the collaboration process.
Agile, Scrum Style
Working in a cross-functional, agile team environment opens the channels of communication and removes the ‘silo’ effect which can result in the dreaded ‘that would have been really great if the developer only knew’ project. Even better, when an agile project uses the ‘scrum’ methodology, it’s broken down into smaller, incremental releases with multiple iterations (referred to as a ‘sprint’ ) so everyone on the team communicates frequently, by design.
A daily stand-up (‘scrum’) meeting with the integral members of the team encourages verbal communication and interaction for matters directly related to the current tasks at hand. As a designer on the team, those daily ‘check-ins’ are the perfect time to involve the developers and to ask the all-important questions before you even get started on designing that next component. Questions such as, 'Is it reasonable for this project to include a custom twitter feed?' or 'Is the out-of-the-box Drupal module required to meet the (development) budget?' Wouldn’t it be awful to design a spectacular, custom twitter feed (of course just what your client wants and LOVES) only to find out developing it will drive the budget into a disaster zone? Prevent that disaster by establishing regular, open, and frequent communication with the developers on your team.
The Project Manager
Speaking of budgets, the all-important Project Manager is key to guiding the way for successful communication between everyone on the team, so be sure to involve them in all design related conversations. The PM can help initiate feedback from the developers when needed, document any potential issues that might arise, and help guide the way to ensure the scope of work remains attainable for the project’s budget and goals.
Meeting with the client to review and discuss the designs (or working website components) is valuable for both the designer and the developer. This is the best time to learn exactly what the client expects from the website and to answer any questions they may have. Benjamin Franklin once said, “Tell me and I forget, teach me and I may remember, involve me and I learn.” Involving the developer in these important conversations with the client will eliminate confusion, and help clarify the anticipated behavior or appearance of the end product.
When designing for a CMS like Drupal, often the client will share administration preferences for how they want the system to behave, or perhaps request extra options they would like to have available. With the developer by your side, they will hear the client preferences for themselves in order to provide insight for those ‘above and beyond’ requests. This will help keep the project on track and ensure you’re not making any promises that cannot be reasonably kept. Recently, I designed a component that included an image on the left side with copy on the right. The client loved the way it looked, appreciated the value of reusable components, and found the perfect place for it to hold some content on another page. However, the design would only work visually with the image on the right instead. Our developer was able to create the component with the option for the Drupal administrator to ‘justify’ the image on the left or the right, therefore, making that component truly ‘multi-purpose’ – and with little investment of time or resources. That was accomplished all because both team members were involved in the conversation with the client in order to understand the request and find the best solution in a timely manner.
The ‘Retrospective’ at the end of each sprint cycle helps to improve the team’s competency and interaction. The goal of each session is to provide positive, constructive feedback so everyone can learn and grow. The sprint structure is based on Pendleton’s rules: What was done well? What could have been done better? What can we improve next time around? A recent example that was helpful for me when the question was asked: “What can we improve?” the answer was, “Every time a revised design version is posted in Jira, please include include ‘next steps’ at the end of the comment so everyone knows what the plan is.” Now, if I step away from the project for another priority and come back to it later, I know exactly where things were left off once I return by reading the last comment posted to the ticket.
Thoughtful and Organized Processes
There are many popular resources available for project management, even some great free open source solutions. Great for agile teams, we use Jira – a communication tool used to plan, track and manage all parts of the project on one ‘board’ that everyone on the team has access to. Every version of every wireframe and design is posted to a ticket on the board, notifying the developer (and others) on the team it’s time to review and give feedback. Another benefit is the historical reference it provides for the design files and the comments that lead to important decisions that were made, ie. 'Why did we decide the video can’t be used here?' or 'What was that Drupal Module you had in mind for that again?'
Most of us speak English, but not everyone speaks ‘Geek.’ Using the same language when it comes to technical terminology is critical to ensuring nothing gets lost in translation. Always go out of your way to be perfectly clear so the developer is on the same page. For example, the option to “filter” is not the same as the option to “sort”. Or, in the world of Drupal the term “paragraph” doesn’t usually imply a group of text on a page. If you design for Drupal the glossary of terms is a reference you shouldn’t go without.
A developer once said: “Always code as if the guy who maintains your code will be a violent psychopath and knows where you live.” The same goes for designs. When a design firm has multiple designers working across multiple teams, the naming conventions for the design files should remain the same for every project. When designer #1 names his files CLIENT-NAME_HOME-PAGE-DESIGN-V.A-1, and designer #2 names her file home-design_clientname_version_1a, you can’t blame the developers for wanting to poke our eyes out! Pick a sentence case, pick a naming system, number and label every screen. Consistency is key, especially in this case, so use the same approach for every project. Better yet, version control your designs, name them for the function they serve (ie, clientname_home, clientname_about, etc.), and everyone will go home happy.
Walk in Their Shoes
Website designs are created only after we know and understand the goals and challenges of those who will use that website, ie, the ‘Users’. Sharing the stories written from the perspective of the user (‘User Stories’) with the developers on your team will help them think more like a user and better understand their needs. User stories convey the product’s purpose and functionality, and often start something like: “As a user, I want to... enter my zip code and be provided with a list of (linked) stores where this product is currently in stock.” Writing effective User Stories takes practice, and should be small, detailed, and specific.
As a designer for Drupal (or any CMS), we have the added layer of another set of users: the Drupal Administrator(s). Often a key stakeholder in the project, the needs of the person (or people) who will be updating website content on a regular basis should always be accounted for during this process. Including the (Drupal) administrator in the User Stories is a great way to include their needs. The developer will not only understand the user of the website but also what the administrator will expect one the site is live and it’s time to make that first update. An example might be: “As the Drupal Administrator, I want to... change the text on the CTA button, and have options for changing the color with a predetermined list of brand-friendly hex codes.” If you’re lucky enough to work with an attentive developer (like I am), they might even share an idea or a solution that you had never thought of.
Design Hand-off Documentation
Your designs just might be the most beautiful thing your client has ever seen, but they can’t ‘speak for themselves.’ Probably the designer’s least favorite thing to do is ‘documenting things’, but it’s just as important as the design itself when it comes to successful implementation. It’s kind of simple, really: you can show them how it should look, but if you don’t tell them (or show them) how things are supposed to behave… you cannot expect to control the results. Here is a story shared by my friend, a developer: “Thinking about ideas on how Design and Development can come together, I thought about a recent project and how I felt somewhat in the dark at the beginning of the development cycle. There were detailed wireframes that looked awesome, but I didn't know what all the components pictured were supposed to do, what content they represented, and where links should take you. It seemed to me all that information was probably discussed in the design meetings with the client and I wished I had been in those meetings listening and asking questions. We hadn't documented the information anywhere so I had to ask the client about everything all over again.” This painful story that could be avoided by including the following:
There are different ways to annotate wireframes and design mockups, and many tools available that can help ease the pain. However, the notes are provided they should serve two audiences: the client and the developer. Depending on the situation, separate documents can be targeted to the specific audience, or you can use a color coded system and include them together. Just be sure the information is clear. A few things about annotations:
- Keep it short and sweet.
- For the client: focus on user (and administrator) benefits & design reasoning.
- For the developer: focus on technical details. Include both frontend (ie, hex codes) and backend information (ie, ‘this button links to’, or ‘include a maximum character count of 500’, etc.).
- For each component, use callout numbers with the associated number and note on the side of the screen.
- If you’re including notes on the same file as the design, make sure they’re placed in a separate layer so it’s easy to turn off whenever needed.
While not meant to inform about layout or structure, a style tile serves as a reference to inform the development team what they need to know in order to create the look and feel of the new site, as intended. At the minimum, they should include the color pallette (with hex values), font families (with size, lines height, and colors defined), visual patterns such as links and buttons (with font, color, sizes) and their hover and/or active states. Usually determined by project scale and budget, tiles can begin as simple ‘mood boards’ and later develop into a more elaborate ‘element inventory’.
When mockups include interactive elements you’re able to provide a clearer picture of how the product should behave. A prototype is a working model – a living code reference – of the design developed prior to website implementation. An interactive example can be beneficial not only for client review and for user-testing interactions and workflows, but also to inform the developer of technical specifications otherwise left to a document or annotated wireframe.
Organized Digital Assets
I heard a developer once refer to their company’s digital asset library as the ‘big, black hole’. Don’t let your team fall into this common trap of an unorganized folder system, where teammates go in and never return. Every design project should have the same file structure, so everyone knows where to find what they need. As with most things in today’s digital world, lots of tools are available and created just for this task of ensuring organization and consistency across your visual asset library.
Did you ever hear a developer ask: “Is the image field on this page required or optional?” or “Where should that button link to?” Streamlined modern web design processes often design by reusable components. Especially when designing a large website, a great way to keep track of all the details about each component (and possible variations) is to use the good ole’ spreadsheet. Simply list the components in one direction and each page template in the opposite direction. Each cell can inform about the details of that component such as if it’s present on that page, and include any specific details the developer might need. An example might be, ‘Component title’: ‘Interactive Team Cards’, with a note in the appropriate cell: ‘Row of (4) cards. Each card includes fields for an Image (.jpg or.png profile pic at 150px), Name, and Title. The user will hover/tap to read a brief bio (max character count: 350) and (optional) social media links.’ As the project advances and designs are completed, be sure to link each design file so the developer has easy access instead of making them search for it.
No matter what, always keep that in mind it’s a team effort. Hopefully, you work on a team who encourages collaboration and values those who aren’t afraid to ask questions. (If you don’t, Mediacurrent is hiring!) Ask questions, ask lots and lots of questions! Chat apps are perfect for developing a personal, team culture and can help to make the design and development processes an enjoyable journey for everyone. We use Slack. Share a joke, ask a technical question specific to the project, or even integrate source code management functionality (such as GitHub) so everyone can be a part of the design to development process as your beautiful design turns to code… just like magic.
5 Questions to Get Your Designs Past Large Review Boards | Video
Designing Websites for Everyone | Blog
Preparing for a Drupal Redesign | eBook