- June 25, 2015
Channeling Your Back-end Developer
- @auraseltzer
- Senior Designer
You’ve heard the assertion before: Designers should learn how to code. Reading through the many articles and comments on the topic, this discussion has focused predominantly on front-end development. Yes, comps fail to capture behavior and the in-betweens that bring your responsive designs to life, but crucially, front-end code isn’t the only step to actualizing your designs. Even if your coded styles remain faithful to your design intent, it’s your content that will put that design to test. If you care about the way content should look in your designs, you should also care about the logic that powers it.
Imagine you’re designing a template for a blog article. You’ve introduced styles for elements like an article title, byline, publish date, etc. You’re also planning to establish a sidebar that lists other pieces of content related to the article—maybe an upcoming event, another piece by the same author, or a topically related article published a few weeks back.
While you’re determining what pieces of content to introduce, how to style them, and when to reuse pieces across other sidebars in your site, also ask yourself how that content arrives there in the first place. Here are 25 questions to help you more fully consider your project’s back-end work while in the design phase.
- Should the heading for your sidebar be hard-coded, an open field, or based on a dropdown selection in the CMS?
- If it’s an open field, how should you label it?
- Is the heading optional or required?
- Is there any direction or help text you can provide to clarify the heading’s purpose?
- Where else on the site can this same field be used?
- Are the related items beneath the heading manually selected or automatically pulled in?
- If they’re manually selected, what types of content can be featured?
- How often should new items be selected?
- If they’re automatically pulled in, is the content coming from this site or elsewhere?
- What happens if there aren’t any items selected or available to be pulled in?
- How do these items relate to the article in the CMS—by a field, a dropdown selection, or because they’re tagged or categorized similarly?
- When do you establish that relationship—when you publish the article or publish the other item?
- How should items be ordered—alphabetically, based on recency, or another way?
- Are any/all of the items presented with thumbnails?
- If so, are all thumbnails the same size?
- Where else does that thumbnail appear on the site?
- What metadata should be presented with each related item?
- Does that metadata change depending on the type of content?
- Are there any links in the metadata?
- If so, where do those links send the user—an existing page or a customized listing?
- Is there a limit to the number of items you’ll display?
- If there is no limit, does the design break?
- If there is a limit, is there a way to access additional items—maybe a link to view all?
- Is the text for that link manually entered or automatically created once it’s needed?
- Do smaller screens present the same number of items and the same metadata?
While these questions are specific to one module on a single page, the line of thinking can extend. If you’re unsure which questions to ask, work with your developers to learn how they analyze your designs. Start a dialog. More important than being able to answer these 25 questions is deciding the best way to document your answers. Design intent remains simply intent if it’s not shared. You could annotate your wireframes with CMS-specific notes. Maybe you feel more comfortable elaborating on elements in a spreadsheet. If you’d rather just meet to discuss your designs from a back-end perspective, that’s cool too. Find a method that works for you and your team—and suits the particular project and client.
When it comes to deciding how designs will function on the back-end, designers should join the conversation.