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

Team cultures and norms that lead to great design execution

No action items yet

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) ? 8 : "7" }}

{{ answer_favs.includes(233) ? "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

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) ? 3 : "2" }}

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

Share

Decide which design patterns to deprecate, which to support, and which to create

2 contributors · 3 action items

Linzi Berry
- Create
  
  • When first starting, make sure you have the basics covered. Every page needs a button, right? • As the system matures, align with product planning. If you see that a bunch of teams are going to be working on surveys, you could also plan to work on survey elements with them collaboratively. • Notice trends. If you see three designers working on something and all solving it a little differently, you can propose it becomes a pattern. • Lastly, helping those who are struggling. If a product designer is having a hard time getting an unsupported component approved, the system can step in and help them get it through the door.... See more
- Maintain / Support
  
  • If there is a bug in a system component, that is priority 0. System components are used everywhere and if they break, they break everywhere. Fix the bugs immediately! • Listen to your engineers. If you're fortunate, they will reach out with feature requests for one of the system patterns (because their designer changed it slightly.) Get to the root of why it was changed. Just cause they felt like it? Because they didn't know the rules of the pattern? Because of a legitimate use case? • Decide, as a team, if that new feature is worth supporting. You can do this by assessing if it still follows the goals of the pattern or breaks them. • Ask the team if they'd be willing to contribute their new feature back to the pattern or if it's something the system team should take on. Contributions are the best!... See more
- Deprecate
  
  Always keep an eye on which components are being used and which aren't – through code (easier) and design. • Is there still a need for the pattern, but the way it was originally solved didn't work? If so, try to look at how designers are solving it now and better understand the root of their problem. • Was the use case for this pattern deprecated as well? Kill it. :)... See more
{{ answer_likes.includes(268) ? 4 : "3" }}

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

Share

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) ? 11 : "10" }}

{{ 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) ? 5 : "4" }}

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

Share

Increase team member adoption of the design system

3 contributors · 10 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) ? 5 : "4" }}

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

Share
Dustin Tanner
- Make a great product
  
  If you build it, they will come. If you make it great, they’ll use it. As the creators of design systems, our customers are designers and engineers. Our job is to make a system that’s easy for them to understand and use. Put your customers first. Understand their needs. Make a product they love so they can do the same for their customers.... See more
- Be the source of truth
  
  To be trusted, your system must be the truth. There will always be variations of your product in code repos, design files, and production but the design system must serve as the source of truth. You must decide where your design system is best represented - a Figma library, documentation website, or code repo. Then, point everyone there. Communicate that as the only place to look.... See more
- Create a medium
  
  Designs systems should be a medium in which to create. Keep the system as flexible as possible. Give folks components and let them make. Patterns will begin to form. Capture and componentize the most repeated patterns but allow others to be created. Don’t control designers and engineers, empower them.... See more
{{ answer_likes.includes(261) ? 7 : "6" }}

{{ answer_favs.includes(261) ? "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) ? 7 : "6" }}

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

Share

Get team members to adapt their workflows around a new design system and tooling

1 contributor · 4 action items

Diana Mounter
- Incentivize change
  
  Introducing a new design system and tooling often means changes to the design and development workflow for your teammates, even though you might know why your new design system is awesome, lots of folks don't like change and will be resistant to using it. Becoming the style guide police won't go down well, you need to help people see the benefits of the new design system. Explaining why you needed a new system will probably help—it might be obvious to you, but to others it could seem like an unnecessary change. Follow with how it improves the design and development workflow for people and any other problems it solves. Even if there aren't significant workflow benefits and the change is to reflect a re-brand, most people want the shiny new thing, so show them how it easy it is to get there. In most cases, showing rather then telling if more effective—live demos, screencasts and gifs, and shipping parts of your product using the new system, will all be better demonstrations of the new system than telling someone why it's great.... See more
- Use every opportunity as a learning opportunity
  
  There are many potential touch-points with your design system. Slack, documentation, code review, design critique, and on-boarding are all opportunities to promote and show people how to use a design system. An on-call duty rotation might help your team respond to requests for help more quickly, code review is an opportunity to teach people and link to documentation so they can help themselves in future. Take stock of the many ways people can come into contact with your design system, and get creative about how you can use those opportunities to help people learn.... See more
- Offer multiple options for learning
  
  People learn in different ways—some folks like a bit more hand-holding, while others prefer to learn more autonomously. Documentation is important and will help reduce the number of questions you get, but no matter how good your docs are, there will also be lots of folks who just won't read it. Providing alternative opportunities to learn will help, this could be bookable pairing time, a regular open office hours that anyone can join, or a planned training session. For the self-learners, tutorials or getting started guides can be a great way to learn, and a sandbox environment that has your design system already installed will help people get a feel for the new system quickly. Design system parity in design tools is as important as making it available in code so that designers and developers can speak the same language—make sure you make it easy for folks to get the latest design components too! Often a combination of tactics works since people want different types of resources and help depending on the stage they're at. Prioritize the approaches that work best for you and your teammates. This might feel like a lot of work, but remember anything you do for your new design system will also be helpful for new hires on-boarding into your company.... See more
- Work with early adopters
  
  If possible, work with folks who can be your early adopters while you're building your new design system. They can help you test new patterns and give feedback as you develop your system. Early adopters who speak the language of your new design system, and have had input into how it was developed, will become champions of the new system. They can help other people learn how to use it, help increase it's adoption, and hopefully spread enthusiasm for using it. Ideally you want champions embedded over a cross-section of your organization to gain widespread adoption. Remember to thank and reward the people who have helped you develop your design system, it's likely better because of their feedback, and you want them to encourage others to work with you in future.... See more
{{ answer_likes.includes(262) ? 6 : "5" }}

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

Share