Playbook - Achieve your career goals

Cancel

{{search_results.questions.label}}

Suggest a goal"{{search.query}}"

{{search_results.people.label}}

{{person.full_name}}

{{person.current_description}}
{{person.action_items_count}} {{person.action_items_count == 1 ? "action item" : "action items" }} No action items yet

Follow

Suggest a goal

A little context goes a long way...
Only you can see your suggestions

Playbook helps designers achieve their career goals.

Get your first Product Design job
20 contributors
Grow as a Design Manager
34 contributors

Decide if freelancing is for you

1 contributor · 6 action items

Coleen Baik
- Clarify your priorities.
  
  So you’re thinking of going independent. Are you able to explain why freelancing appeals to you, clearly and succinctly? What does that life give you that a salaried one can’t? People become freelancers for a host of different reasons: family, health, artistic pursuits, the desire for more autonomy. Freelancing isn’t easy but can also be extremely rewarding. But those rewards depend on your priorities, what you’re willing to give up for, and how you plan to pursue, them. Paying the bills is only a part of it. You don’t need to have all the answers up front, but it’d be wise to have an idea of what you want the big picture to be before making the shift. List out your priorities and take a good long look. How does freelancing support or complicate their fulfillment? Be brutally honest with yourself.... See more
- Weigh the risks and understand the responsibilities.
  
  Write down the pros and cons of salaried versus freelance life. Freelancing isn’t just about choosing which day of the week will be Sunday, or working in your pajamas. You’ll have a lot more to take care of than just client work. You’ll pay taxes four times a year instead of once. Healthcare will cost a lot more. $500/mo isn't unheard of for single coverage PPO (high deductible, no dental or vision) even as a healthy young person with no pre-existing conditions. Get creative in navigating this brave new world. Taken one step at a time with some forethought, it can be done. If you’ve a domestic partner who can add you to their plan, great; Stride Health is a good resource; an FSA card is worth looking into. You’ll pay for all of your software, tools, conferences, and classes. You'll be your own HR, salesperson, CEO, manager, and PM. You'll have to deal with awkward situations (like clients who don’t pay on time). Expect to make mistakes, iterate on structure, and refine process. Does this give you cold feet or feel like an adventure? Pay close attention to how you feel as you assess what freelancing entails.... See more
- Talk to people.
  
  The less of a black box it is, the less stressful it'll be, and you’ll be able to reserve more of your headspace for the actual work of setting yourself up as a freelancer. You can start by sitting down to compose key questions, then asking some veterans. Why did they start? What did *they* do when a client balked at their rate? What’s the biggest lesson they've learned? There are a ton of freelancers on this platform (👋) and others like Twitter. Reach out, come prepared with questions, buy them coffee. Listen closely and don't forget to thank them. Striking out on your own can be scary, and it helps to hear others’ personal stories while building on their knowledge.... See more
- Assess your safety net.
  
  Money will no longer magically show up in your checking account every two weeks. Sad, I know. Holidays and weekends may not seem so shiny anymore, and the idea of taking vacation might be stressful, not fun. It's normal to be stressed. Do everything to mitigate this stress. Take a look at your savings, for a start. A well-cited rule of thumb is at least 3 months' worth, but I would recommend a year's worth (or more) for emergencies and dry periods. No more 401K matching either so you’ll need to set up alternatives (IRA, SEP-IRA) for retirement as well.... See more
- Form a strategy.
  
  How are you going to get gigs? You can put yourself out there among the hundreds in a sea of portfolios, but ideally you get introduced to projects through personal connections who understand your skillset and can vouch for your expertise. Without a strong network, you may be subject to taking on unedifying jobs purely for the sake of paying the bills, and if that’s the case you may as well keep the security of a regular paycheck. Prepared to put out a few feelers? Put a portfolio together. Get some endorsements in place. Reach out on Twitter or other networks where you can get seasoned folks to help you spread the word. Many often can’t take on all the gigs that come their way so they’re relieved to pass on some overflow.... See more
- Give yourself permission to fail.
  
  Once you’ve done your homework, squared yourself with the risks, balanced your books, and can clearly articulate why you still want to freelance, take a deep breath and come on over to the dark side. So maybe everything isn’t as organized as you’d like. Maybe you have only a vague whiff of a Plan B, no partner, nor a mountain of savings. But you still want to do this! Go for it! What’s the worst that can happen? So you make some mistakes, get some curve balls, return to being on a payroll. You might realize that freelancing isn't for you, or that it’s not for you *yet.* It’s not a crime to crave a regular paycheck, cheap healthcare, or paid vacations. But if you don't give it a try, you won’t know the joy that comes from, and whether it’s worth, steering your own ship, when and how you’d like.... See more
{{ answer_likes.includes(233) ? 5 : "4" }}

{{ answer_favs.includes(233) ? "Saved" : "Save" }}

Share

Scope a project with a client

1 contributor · 3 action items

Coleen Baik
- Listen.
  
  Start with a conversation (or two). In-person is great but at this juncture phone or video chat is completely fine! Introduce yourself and frame your expertise, but let them do most of the talking. Before the meeting it often helps to think about the questions you want to ask ahead of time about schedule and expectations. If it doesn't seem like a fit at this time, kindly tell them so. For instance, you might be overqualified for the specific project. Or they might need a lot of pixel-pushing and you prefer to focus on strategy. In this case your time as well as their money would be better spent if they went with someone else. Give them a referral if you're able. Perhaps you're inclined to help out in an advisory capacity in the meantime.... See more
- Lead.
  
  If there's good chemistry and alignment, don't be afraid to be proactive about how you'll spend your time together. Lead with what resonates with you: your client wants a job done well, and you want the job to be enjoyable as well as challenging. These things should not be mutually exclusive. If you get the sense that a fledgling team is overwhelmed with a disorganized system, you can offer to help review their information architecture. If they're struggling with a dull brand, perhaps you can lead a workshop to kick things off in a new direction. If you like doing these things, and they would greatly benefit from your expertise, why not prioritize them in your time together? Clients are so burdened with their own tasks that they're often relieved to have someone else take the lead in defining the collaboration. Look for open doors, and step through.... See more
- Be explicit.
  
  It's easy to for the client and the consultant to have startlingly different understandings about something that can seem so basic. If you have the slightest doubt, ask. A good way to get clarification is to repeat back to them a summary of what you think you've heard so far, or your version of a complex product detail they just explained. Likewise, be very clear about what the client expects to have in hand at the end of your time together. What form will the deliverables be in? Will you also be handling production? Don't assume that "half-day" means 4 hours, that they'll pay for expenses incurred, or that there won't be travel involved. Spelling this all out will force them to be specific about, and you to be clear on, load and scope. I usually put my requirements and work proposal in a 1 to 2 page letter of agreement. The client and I revise as needed, together. The more established clients will have their attorneys incorporate it into their own legal documents which will serve as the final contract.... See more
{{ answer_likes.includes(246) ? 1 : "Like" }}

{{ answer_favs.includes(246) ? "Saved" : "Save" }}

Share

People to followView all

{{person.full_name}}

{{person.current_description}}
{{person.action_items_count}} {{person.action_items_count == 1 ? "action item" : "action items" }} No action items yet

Follow

View all

Roadmap the evolution of your design system

1 contributor · 9 action items

Linzi Berry
- Define the problem
  
  A design system is an internal product. Like any product, it's good to start with understanding the real problems your company has that a system can solve, but also be open to the possibility that not every company needs a design system. Questions to ask: • Is your company in hyper growth? or at a size where not everyone can attend a review and agree on a solution? Are multiple designers trying to solve the same problem, unbeknownst to each other? • Is your code built in one offs? If you need to update the style of a button, do you need to hunt for every use and adjust it? • Do you designs and code meet a11y compliance? are they ready for localization? Do you have solutions for every state or edge case a component might encounter?... See more
- Set goals
  
  Once you have your problems defined, you can create goals that have business impact. Some examples might be (based on the problems above): • Deliver consistency/coherency and predictability in our products • Reduce design and engineering time and debt • Raise the quality of our experiences for every person and every edge case... See more
- Get buy-in with a test project
  
  Many design systems start as grass-roots efforts, but in order for them to gain traction beyond the designer and engineers who are already on board – leadership buy-in is a must. Prove the worth of a system with one portion of a system. I recommend messaging templates + guidelines or buttons and make sure to show off an audit that captures the current state vs the benefits of the proposal.... See more
- Support
  
  Educate teams on how to use core elements and apply the principles to build their own. The biggest way we do this is through documentation. Additionally, lecture at all-hands and brown bags, teach classes, host office hours, and answer questions.... See more
- Adopt & Migrate
  
  Participate in the adoption and migration of current designs and code into the system. Promote the adoption of the system elements when teams create new features. Migrate features and flows that teams don't own (or don't plan to work on) into the system for them.... See more
- Build the system
  
  This is what most people think of when they talk about design systems. Build & maintain flexible, foundational elements and components to your company's standards. Work with teams to prioritize which elements will have the greatest impact. Make sure they solve the root cause of the real need and work every single time, for every person, and every edge case.... See more
- Build a dedicated design & engineering team
  
  Start with a small amount and build over time as needed. We started with two designers focused on mobile, grew to two engineers (one Android, one iOS), and now have more engineers, illustrators, motion, web systems and tooling.
- Build tools
  
  Build tools that help designers and engineers use your system is a fast and easy way. The easier it is to use the system, the more likely they are to do it.
- Accept contributions
  
  Encourage designers and developers on external teams to contribute back to the system. Think about creating something to reward contributors, like an enamel pin or stickers.
{{ answer_likes.includes(236) ? 8 : "7" }}

{{ answer_favs.includes(236) ? "Saved" : "Save" }}

Share

Keep design and engineering systems in sync

1 contributor · 3 action items

Sam Soffes
- Always do a kickoff meeting
  
  When starting a new project, always do a kickoff meeting. It can be something as small as adding an icon to a button that previously only supported text or a huge new multiscreen flow. The designers and engineers working on the project meeting together before engineering starts to answer questions and iron out final details will make implementation go much smoother.... See more
- Track changes for each team
  
  When you make a change to anything, it is important to track this in your task management system. Be sure to create a task for design to update their libraries and documentation as well as for engineering team to implement it on their platform. Being sure to create tasks for everything helps prevent things from getting list.... See more
- Do regular audits
  
  Set aside time every month or so to audit all of the naming and features of everything in your system on each platform. Even if you are extremely diligent about keeping things in sync as you build it, it is very easy for things to start to drift away from consistency. Create tasks for each inconsistency for design and engineering and knock them out.... See more
{{ answer_likes.includes(256) ? 4 : "3" }}

{{ answer_favs.includes(256) ? "Saved" : "Save" }}

Share

Increase team member adoption of the design system

2 contributors · 7 action items

Sam Soffes
- Build trust
  
  When there's a bug in part of the design system—either in a Sketch Library, engineering implementation, etc.—it can greatly impact the whole product. You should be responsive and fixing these issues as quickly as possible so your team can trust the design system.... See more
{{ answer_likes.includes(254) ? 2 : "1" }}

{{ answer_favs.includes(254) ? "Saved" : "Save" }}

Share
Linzi Berry
- Empathize with teams & their users
  
  Adopting and migrating a product to the system is a huge task for any team. To accomplish this with the least amount of thrash, we have to drive home the benefits a system provides and, arguably more important, how much we truly care about them and their user's needs.... See more
- Reassure stability
  
  After teams are bought in and start using the system, piecemeal updates and additions can be overwhelming and make the system feel unstable. Creating a consistent, batched workflow and announcement process sets expectations and documents why we did what we did.... See more
- Educate, don't enforce
  
  We see ourselves as teachers, not the police. We create documentation as a resource and we present as if we were in front of a classroom. When reviewing work, we always ask questions around the decisions made and follow along the process to how they got there. We studying our designers, and their habits, in the same way that they look at their own users - to try to serve them better.... See more
- Be flexible
  
  Our product teams are closer to our users and innovate faster than us. We know that sometimes the the system won't cover all their edge cases. By approaching our system as a living document, it remains flexible enough to be open to new ideas, challenge what we've created, and pull in new paradigms as they are proven successful.... See more
- Share ownership
  
  Designers and engineers desire ownership of their work and that can be difficult when using a system they didn't create. By creating clear pathways to get involved, we can share ownership.
- Construct communication avenues
  
  Direct messages distract and only provide the answer to one person. We have constructed communication avenues, with a 24 hour response time promise, to protect our valuable work time.
{{ answer_likes.includes(252) ? 6 : "5" }}

{{ answer_favs.includes(252) ? "Saved" : "Save" }}

Share

Build your design system to be consistent, yet flexible

2 contributors · 2 action items

Sam Soffes
- Define what is flexible and what is rigid
  
  You should define what is flexible and what is rigid in your system. For example, fonts and colors are probably very rigid. You want everyone to always use your brand fonts and colors so the product feels like your product. Component details are usually a bit more flexible. If you had a button that was a specific size and someone needs to change it to be a bit smaller to fit in a new flow, that's probably okay and can still feel on brand. Maybe someone is adding a screen to take photos and they UI should be dark instead of light so they need to customize a bunch of components so work in dark mode. That's also probably fine.... See more
- Provide ways to mix and match
  
  Defining multiple styles for the same component is a good way to make things flexible. You could have a "primary" and "secondary" style for a button component. You could also have a "normal" and "compact" size of the component. You could also allow team members to create their own styles or sizes. Allowing designers to mix and match sizes and styles can open up a lot of combinations that all feel consistent.... See more
{{ answer_likes.includes(237) ? 4 : "3" }}

{{ answer_favs.includes(237) ? "Saved" : "Save" }}

Share

Address legacy code constraints when building a design system

2 contributors · 6 action items

Elliot Dahl
- Understand your constraints
  
  Legacy code can be outdated technology, poorly implemented code, or both. For example, Javascript frameworks are all the rage but they change rapidly. Getting left behind on an old version of a framework can be limiting and expensive to remedy. Sit down with the engineers on your team to understand why your current implementation is limiting your ability to build a great design system. Alignment on the pain points is the key to making any progress on addressing legacy code constraints with your team.... See more
- Evaluate the impact to the end user vs your team
  
  Start with making a list of where your legacy code is hurting the user's experience (e.g. slow login experience). Then make a list of the pain points of working with the legacy code (e.g. spaghetti code that takes awhile to parse). Get the team involved in plotting each user or team pain point on a 2x2 grid to evaluate the cost vs impact of each. Ideally you've identified a few low cost high value issues to address, which is a great place to start. With a fast moving team it can be helpful to run this exercise on a regular basis to ensure you're addressing the most pertinent issues.... See more
- Create a deprecation plan
  
  Take some of the issues you identified in the step above and create a step by step plan to deprecate some of the legacy code that's holding you back. Take into account the product areas and people this change will affect.    The best way to get buy in from team members and stakeholders to prioritize this work is to include them on this entire process.... See more
{{ answer_likes.includes(247) ? 2 : "1" }}

{{ answer_favs.includes(247) ? "Saved" : "Save" }}

Share
Sam Soffes
- Plan to coexist
  
  In a large legacy codebase, your fancy new design system code will have to coexist. Plan how the new things will interact with the old. Having the ability to rollout new things gradually instead of requiring a full rewrite will build confidence in the new system since it can prove itself as you rollout each new thing when it's ready instead of all at once at the end.... See more
- Start to enforce best practices
  
  Jumping into a project with a legacy codebase can feel like the wild west. Bringing some consistency to the existing stuff with automated tools can help make migrating easier in the future. Source code linters to enforce best practice will make life a lot easier as you start migrating things.... See more
- Replace as you go
  
  As you roll out new components, it will make things easier down the road if you can set aside some extra time to remove the legacy one and replace them with the new ones. This will remove any ambiguity about which one to use for new features.... See more
{{ answer_likes.includes(255) ? 2 : "1" }}

{{ answer_favs.includes(255) ? "Saved" : "Save" }}

Share

Build the right team to create and maintain a design system

1 contributor · 3 action items

Diana Mounter
- Find people already doing the work
  
  When building a new team without hiring externally, look for people internally who are passionate about design systems, who take a systematic approach to design and development, and want to solve the problems that design systems solve rather than because it sounds fun (though it is fun for many!). Often you'll find there are designers and engineers already doing the types of work you need to do when working on design systems and they'll be excited to help make it happen.... See more
- Match skills with your companies needs
  
  Whether you're hiring externally or looking for people internally, hopefully you've decided you need create a design system because you can see how it will solve certain problems you're experiencing. The focus of your design system might be to improve workflow efficiency, help you scale a brand to multiple applications, or to effectively launch a re-brand. Some companies start with focussing on their web product, some with native applications. Different types of problems require a different skill set, find people who best match the skills you need.... See more
- Start with hybrids before expanding to specialized roles
  
  Design systems live at the intersection of design and code, so in the early days it's really helpful if you have hybrid designers and engineers. Similar to start ups, when you start a new team, it's helpful if you have people who can wear many hats. A designer with strong CSS skills, even if you're working with other technologies, will be a valuable asset to helping you organize and develop the design patterns you need. Designers who have experience implementing their own designs in production and prototyping will likely already design in a modular way and work well with engineers. Having engineers who enjoy front-end, and have design sensibilities or a background in design, will help you develop your design system in a way that works for both engineers and designers. It doesn't have to stop there—engineers with performance or accessibility experience, designers with content or research skills, or illustrators who can prototype interactions—could all be part of your hybrid team. As your design system and company scales, bringing on people with more specialized roles will help your team do what they've already been doing better, and grow the area of needs your design system can support.... See more
{{ answer_likes.includes(243) ? 6 : "5" }}

{{ answer_favs.includes(243) ? "Saved" : "Save" }}

Share