Design Handbook

---

Overview

---

Congrats on reaching the last phase of CodeLab’s Design Bootcamp! In the past five modules, you learned how to Empathize with your users, Define the problem space, Ideate possible solutions, Prototype your designs, and get feedback from user Testing. As you wrap up your designs, use this Handbook as a guide to working with developers and making sure your designs are ready for handoff, all whilst following good design practices.

Module Length: 25 min

Housekeeping Rules

---

Without good design practices, a project would be mediocre at best. Communication, documentation, and the following design standards apply to all your projects, so be sure to keep these in mind as you go through the design process!

Documentation

Design documentation refers to all the written information in the design process, from meeting notes, project specs, and timelines to progress shots, decision decisions, and design guidelines. While you may think this information can be compiled at the end of a project, the sooner you start the documentation process, the more efficient your project will be. The documents are an ever-growing source of information for everyone, from current members to recruits to stakeholders, to refer to when they have questions about finalized designs, task progress, feature changes, and so on. Not only that, documentation can be an immense help when you’re writing your case studies.

There are a few general practices to follow when you’re making your documentation:

• Keep things updated: Record any changes, decisions, and progress in your documentation as soon as possible. Up-to-date documentation ensures that everyone is on the same page on how the project is progressing, especially stakeholders and recruits.

• Include progress shots: Save files and make copies of your work! Progress shots are a key component in case studies and help others visualize previous iterations.

This may seem like a lot to keep track of, but you only need a few key documents for successful documentation, and it’s not much different from what you already do.

• Research & user tests: What research was conducted and what did you find? Who did you reach out to for your research?

• Ideation: How did you arrive at your solution?

• Design systems: What are the branding guidelines (colors, fonts, styles) and the main components of this product?

• Iterations & design decisions: How did your designs evolve? Why did it move in that direction? Do you have visuals to go with your explanations?

• User flows: How does this product work? How would users experience and use it?

Design Standards

All designs follow the fundamentals of design in aesthetics and functionality. It’s a good idea to take a step back from your work and reflect from time to time to make sure you’re heading in the right direction.

UX Checklist

More often than not, designers get caught up in the aesthetics and lose sight of the UX process while designing. To avoid that, ask yourself:

• Do my designs answer user pain points? When was the last time I referred back to my target audience and research?

• How can I back up my designs with researched-based evidence?

There is a lot to keep in mind while you’re designing, but make sure you check in with your users now and again, whether it be looking at previous notes or holding more user tests. In the end, make sure all your designs can be backed up by your research and fulfills user needs.

Aesthetics Checklist

A design hasn’t reached its fullest potential if it is only effective in solving the user’s problem but doesn’t have the looks to match. This can lead to an unpleasant user experience and a decrease in users. To ensure your designs bring delight to your users, make sure your designs have:

• Accessibility: Can users outside of your target audience understand your product without frustration or confusion?

• Contrast: Are elements distinguishable by color, especially for users with vision impairments?

• Visual Hierarchy: Can users understand the page’s purpose after a quick skim? Are important features visible in a user’s first impressions?

• Grid & Whitespace: Do you have an appropriate grid layout for the medium you’re designing for? Do sections and elements have enough whitespace to be distinguishable?

• Consistency: Does your product have a cohesive style, tone, and design layout throughout all the screens?

• Responsiveness: If you’re designing for multiple devices, do you have defined breakpoints for various mobile, tablet, and desktop views? At what point do designs change based on screen size?

Working with Developers

---

Cross-team collaboration is a key part of real-world situations. It may sound intimidating and difficult at first, but working with developers isn’t much different from working with designers. Let’s explore what that collaboration might look like by first understanding the developers’ project timeline.

Designer vs. Developer Timelines

The project process is different for developers and designers: Developers get a project overview and debriefs with the rest of the team, including designers. They then code the functionality of the product and fix any bugs before coding the UI and checking in with designers to make sure the UI matches and is feasible. Developers will also message designers as they code the UI if they need design clarifications or updated iterations.

As you can see, designers are more involved towards the end of the development process. It’s recommended that designers have user flows and user journeys mostly finished before handing it off to developers as it’s difficult to recode functionalities.

But, that being said, note that development/design handoff is an ongoing process. Handoff does not just happen at the end of each design phase or towards the end of the development process; designs and information are sent to devs whenever there’s an insightful or big progress update. Design and code are not two separate entities, and both must work and understand each other to build a successful project.

Developer Collaboration

Prioritize Communication

If there’s one thing you take away from this, make sure you are constantly communicating with your team. Learn how to effectively present your work and progress and establish the next steps during meetings. Devs and designers need to work together to keep everyone on the same page, even after team meetings, to help the project run smoothly.

• Have all-hands meetings: Make time for a full-team meeting to debrief & discuss the project. General Meetings are a great time for these!

• Updates during meetings: Present the work you’ve completed over the week, the reasons behind your designs, and establish the next steps you and your team should take. Other key things to include for updates are: - Design systems: Make sure devs are familiar with the design system and components so the coded UI follows the design standard - User flows: Have the team thoroughly understand the product’s user flow so everyone knows how the product works

  • Progress shots: It’s helpful to provide visuals with each update, but encourage developers to view the final designs and prototypes on Figma! It’ll be a timesaver for both sides.

• Be assertive yet flexible: Advocate for your users when users’ needs are compromised by developer suggestions. You and other designers are the middlemen representing your users, so be the voice for your target audience. But, sometimes, designs just aren’t feasible, and in that case, be prepared to make compromises.

Create Understanding

Similarly, this may be the first time developers are working with designers. Everything about design would be new to them, from the design process to Figma. Take the time to explain what you’re doing, as an understanding of the design process would foster better collaboration between teams.

• Design Process: Give developers a short blurb on each design phase and the importance of certain things (like research and user tests) to help them understand the design process

• Figma navigation: Encourage developers to learn how to use Figma! You can direct them to the Book of Figma or give them a quick rundown of how Figma works, how to access your designs, and how to export images. Familiarizing developers with the software means more efficient teamwork and a smoother handoff process.

  • Pro tip: Don’t be afraid to ask them about how code works too! A basic understanding of both sides of the project process makes communication easier between the teams.

Encourage Interaction

Coding and designing don’t have to be isolated processes. Having others join in on design or developer meetings creates a better understanding of the project and builds team connections.

• Ask for feedback: If you’re looking for more feedback or are brainstorming ideas, reach out to the developers! This is a group project after all, and the devs might have interesting insights designers might not have thought of. - Feasibility checks: If you’re stuck on a decision, ask developers which designs are feasible/easier to do. Your cool designs don’t do much if they can’t be coded. - Group ideation: Invite developers to brainstorm & ideate with you! They might have some cool ideas, and having more people brainstorm increases the potential of landing on a great solution.

Design Handbook Conclusion

---

And with that, congrats on completing CodeLab’s Bootcamp! From Empathizing with your users to Ideating Defined solutions to Testing your Prototyped designs, you’ve done it all in just a short span of a week, with a complete mini project in hand (be ready to present your project at the second General Meeting!). You learned how to document your work and how to effectively collaborate with developers. All that’s left now is to apply what you learned and get started with your cohort project with your cohort team! We can’t wait to see what you make! Here’s to a great quarter and an amazing year with CodeLab :)