One of the patterns is called “Familiar Tools” talking about the tools programmers use.

Write down a list of your familiar tools. If the list has less than five items, start hunting around for tools that will fill the gaps in your toolbox. This may simply be a matter of identifying a tool you already use but don’t know well enough, or it may involve finding new tools altogether.

I’ve written some in-depth posts about learning the basics of prototyping tools like Form, Origami, and Framer. The “Familiar Tools” pattern reminded me to take a look at my current toolbox.

There are a lot of different tools out there, and if you’re just starting out it can be overwhelming to pick some out to learn. You might even be frozen by all the options.

As far as a hard-skill toolbox goes, here’s what I’d recommend to a new designer. Learn a different tool in each fidelity well.

Pen and paper for lo-fi thinking: Sometimes completely overlooked. Tools for animating microinteractions are fun to use. They’re fun to play with so it’s tempting to jump into super high fidelity and work with motion.

If you’re designing in high fidelity and not testing with actual users, it’s probably too early. Pen and paper can take you a long way when thinking through ideas on your own.

Static mocks for going through flows: Sketch. It’s become pretty standard. At least as far as the echo chamber goes.

High fidelity prototypes for mobile: A good old “it depends”. Just try them out and see which ones click for you. Framer and Origami have great communities and that goes a long way toward the usefulness of a tool. I still want to try Principle.

High fidelity prototypes for desktop: The advantage of the mobile interaction design tools is that they let you try things out without learning Swift/Objective-C or Java and learning the respective development processes.

HTML/CSS is more approachable than any toolset for native development. Right click in the browser, click “Inspect”. Tinkering around, changing values, and seeing the changes might be the best way to start learning CSS.

Get proficient with Chrome developer tools. Or the equivalent in the other browsers. Sit with a developer you work with and have them show you around the inspector and console. It’s a great investment of time.

Visual design: Here’s my biggest gap. Illustrator seems to still be the tool of choice of digital illustrators. I’d love to learn.

As far as soft skills go, they’re harder to sit down and practice. A lot of it comes through experiencing different situations firsthand. (I’d recommend actively avoiding the soft skills such as getting offended about interchanging UX/UI/interaction/product designer titles and thinking up UX analogies.)

Apprenticeship Patterns has a pattern called “Practice, Practice, Practice”. Adewale and Dave talk about having a place where you’re comfortable making mistakes. Again, I’ll connect this apprenticeship pattern to something I read In Deep Work. A lot of the ideas in Deep Work also overlap with the idea of deliberate practice:

Its core components are usually identified as follows: (1) your attention is focused tightly on a specific skill you’re trying to improve or an idea you’re trying to master; (2) you receive feedback so you can correct your approach to keep your attention exactly where it’s most productive.

Many designers already receive plenty of feedback during the design process. (If not, check out my book notes on Discussing Design. It’s a great book by Adam Connor and Aaron Irizary about giving and receiving good critique.)

Deep Work is more about the focused-attention component. If you’re going to spend deeply focused time on something, you’ll want to make sure it’s the right thing. Apprenticeship Patterns provides some guidelines for picking exercises for practice:

Make sure that it’s just a little harder than one you know you can easily solve. You should have to struggle to solve it the first time. Solve this exercise from scratch once a week for the next four weeks, and observe how your solutions evolve. What does this tell you about your strengths and weaknesses as a programmer?

Day to day design work might not always stretch those skills. If that’s the case, sit down and identify areas you want to grow. Then find or create exercises of your own for practice.

When I started learning Framer, I learned a lot by trying to re-create animations from different apps. These exercises were usually scoped to a single interaction. I tried re-creating pull-to-refresh animations, I tried re-creating parts of the Material Design launch reel, I tried re-creating examples from the Framer docs.

The great thing about Framer is that the source code is available for a lot of things you’ll want to do. You can always attempt and then compare your approach to a working example and see where you can improve.

It’s a little different for Sketch and the other interaction design tools. It might not be as easy to find source files to learn from. This is where it’d be great to have a mentor to look at your work. You can share your approach to different things and they can explain where you can improve. I seem to always learn some sort of technique when I watch others using Sketch.

Apprenticeship Patterns talks about going deep into new subjects as a good way to learn. The risk with going in the deep end is that you’ll sometimes get in hairy situations. Competence can be the edge of the pool: something familiar that you can grab onto. They discuss applying the “Retreat into competence” pattern:

short-term fix while you gather your strength to bounce back. Set a time limit (or “timebox”) for yourself, such as “I will spend the next 10 minutes refactoring the JavaScript validation for this page before I optimize the SQL queries that provide the data.” Or “I will spend the next four hours implementing the command-line interface for this tool before I learn how to call this third-party SOAP API.” Or “I will spend the rest of today improving our test coverage before taking on the job of optimizing our code that is affected by Python’s Global Interpreter Lock.”

I tried thinking about how this could be applied by designers. A lot of the apprenticeship patterns have you looking at how you can stretch your knowledge. You look at valuable tools and techniques you’re not familiar with and deliberately practice with them.

As a side effect, you’re thinking through tools you are familiar with. These comfortable tools are the ones you can retreat to. That might mean taking a break from the latest prototyping tool to retreat into Sketch. Or taking a break from thinking through multi-screen flows to focus on some motion interaction with Framer.

(I’m trying to write book notes compilations one section at a time. One excerpt per day with the goal of filling one iA Writer screen up. About 350 words.)

This week, I’m focusing on Apprenticeship Patterns, by Dave Hoover and Adewale Oshineye. Dave and Adewale talk about software as a craft and give guidance on how you can improve as a craftsman. It’s targeted toward developers, but a bunch of it applies to designers. (And even beyond that.)

One of the patterns is called “Expand your bandwidth”:

Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.

They discuss setting up Google Reader to consume RSS feeds. They discuss one of the pitfalls that seems all too common today:

It’s possible to become obsessed with gathering and consuming new information, particularly as it becomes easier and easier to get at up-to-the-second thoughts on the most prolific thinkers in our industry. Some people could become lost in the sea of interesting information, and never come back to actually crafting software.

The book is from 2009 and there’s no mention of Twitter for keeping up with the latest information. That said, I was a pretty heavy Reader user and was just as addicted or even more so I ever was of Twitter. Reader made a lot of full content readily available.

One day, I remember stepping back and thinking, “Do I really need to see basically the exact same news from Engadget and Gizmodo?” That started the culling and then I was able to really cut things down and then eventually accept that I don’t need to read every. single. thing.

Because there’s value in all the available information out there, it might seem like a good idea to seek out as much of it as possible. Cal Newport discusses this in his book Deep Work:

This argument, however, misses the key point that all activities, regardless of their importance, consume your same limited store of time and attention. If you service low-impact activities, therefore, you’re taking away time you could be spending on higher-impact activities. It’s a zero-sum game. And because your time returns substantially more rewards when invested in high-impact activities than when invested in low-impact activities, the more of it you shift to the latter, the lower your overall benefit.

It’s important to remember that time taken by shallow activities could be applied to more important activities. Having taken extended breaks from different social media, there’s major FOMO. It goes away once you realize enough times that you never really miss much.

I started a refresh for this site. I want to continue writing regularly. However, I don’t think it will take the form of long articles about design sprints and design tools. I started writing newsletters to experiment with shorter writing, but even those took longer than I expected each time. I still want to send something out. For the next issue, I’m going to try writing a short post each day and collecting those to send together bi-weekly.

I would write the newsletter and then re-write over and over and try to make the whole thing coherent. Sometimes things got a bit forced because links just don’t always relate. And I was finding myself putting it off because I was looking for very large chunks of time to work on it. And of course, I wasn’t finding those large chunks of time.

Writing seems similar to working out in that you’ll see improvements through consistency. You can’t work out for 8 straight hours to make up for 8 individual hour-long workouts.

I’ll share links and book quotes and share some thoughts to how they can relate to different stages of a design sprint. Sometimes. Other times I’ll share how they relate at least to design.

Thanks for bearing with me.

Last week, I read Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. I picked it up after seeing Ale Muñoz (designer/developer working on Sketch) recommend it as a resource for learning how to teach in a response to Koen Bok (Framer co-founder).

It’s about improving as a developer and looking at programming as a craft. A lot of it can be applied to improving as a designer. (Not to mention a ton of other careers.) One of the patterns discusses the importance of writing down what you learn:

When Dave was Reading Constantly during his apprenticeship, he kept a text file in which he transcribed all the quotes that shaped his learning. Over the years, that file grew to contain over 500 quotes, and Dave eventually decided to upload it and share it online.

(And “Reading Constantly” is another pattern I’ve been trying to apply.) Over the years, I’d like this site to have over 500 quotes. This is one of the first.