JTBD doesn't fit neatly into a template or canvas, and is more a framework than a specific workshop activity. If you really want to apply the framework into your design practice, I'd look into the articles/books that Bob Moesta and Ryan Singer have written on the subject. Moesta has shared a number of JTBD interviews online and hearing those may help.

Andrew's post is how I felt a few years ago. Sketch was a breath of fresh air compared to Illustrator and others. Symbols really changed workflows for the better.

Fundamentally, Sketch's bet on Mac only isn't panning out. In fact, the initial reason I switched to Figma wasn't by choice: Our client only had PCs so we couldn't share design with them.

Culturally, Sketch is a cloistered ecosystem. If you can't afford a Mac, you're out of luck. Contrast that with Figma, which runs on so many more devices accessible to more people worldwide. Figma's ability to build a global community of users, that's the killer feature every other tool is lacking.

Still, I like Sketch and even though our team switched to Figma years ago, I still root for them to succeed — even if only to keep Figma on its toes, and the market competitive. That said, the hill that Sketch needs to climb gets steeper every day they don't ship the features they previewed a while back.

I see it more as additive to Figma vs. alternative. For me, Figma is awesome to prototype 80% of the flows I'd like to demo. Framer gets me the extra 20% interaction/animation bits that isn't quite yet possible in Figma.

But until Framer can stand up a shareable design system and custom plugins, it's not replacing Figma any time soon.

I use Figma on iPad Pro and wrote a Medium post about it. https://medium.com/@nelson.taruc/figma-on-ipad-pro-a-survival-guide-5981e88fdec5 Main use case is to "fill the void" when I don't want to carry my laptop around, but the article may help add color to that use case.

Hi Taylor! Here's what we do. Two design challenges, less than an hour total. Done in the presence of one or two other co-workers (not just designers, but the people most likely to work the hire on a daily basis) who evaluate with a pre-created grading rubric (super important to avoid bias).

We have a few tests to choose from depending on the role, but here's my go-to default. Find a case study of an actual app design (e.g. any long-winded post on Medium lol) that spells out some random designer's process. The more obscure the better (this challenge is most effective if the candidates have never seen it before).

Give designers time to read the case study (e.g. 10-15 minutes) and take notes if they wish.

Then have the candidate present what they liked or disliked about the case study, and what they would've done differently. Finally, ask the candidate whether they would hire that designer at Lucid or not, and why.

I have to note we don't do any follow up questions except to clarify anything confusing the candidate said. We intentionally leave the like or dislike question open ended to let the candidate fill the space (and avoid poisoning the result with leading follow-ups).

This design challenge doesn't require a whiteboard, take home or any of that junk, but definitely will reveal how the candidate thinks on their feet, presents their case, and the type of designers they prefer to work with (or not). And this specific test takes 30 minutes.

Here's the important part, before you use the case study in interviews, have each of your designers take the test first! This will inform your grading rubric of things you should expect or not expect to hear, and help you see whether the case study is too hard or easy to evaluate.

Final note, the grading is done independently and alone. Only after grading do the co-workers share their opinions (again, to avoid influence and bias).

I think your approach is right, one source of truth reference (iOS it seems in your case) and some diff screens as needed for others. One thing I'd also consider are annotation layers, e.g. a layer group for pointing out differences on Android and a layer group for mobile web. Then at regular interviews just duplicate the file like a "design freeze," turn on the Android/Web layers, fade out the iOS layers a little and you have stand-alone guides.

That way you get to manage just one core file (with two clones) vs. 3 separate ones.

If you need to hand off to devs, design tokens like Ryan P. mentioned are a great idea, as well as abstracting them out to a separate file but linked to your library(ies). I'm assuming you already have components in a shared library so obviously that is the best approach for managing those.

Good luck!

As a mobile app designer, font licensing is incredibly frustrating to navigate. Unless your company/client is willing to build their own bespoke font for mobile, It is frustrating to try and level-up an app design with a pay-to-use third-party font. The price models from font to font are neither consistent nor scale predictably.

Shape Up by Ryan Singer of Basecamp made me rethink everything I knew about the agile process and how to approach product development with a focus on demand vs. supply. If you’ve ever been frustrated with “Agile” sprints as a designer or product owner, this is a must-read.

I was bleh about Pentagram's work on Slack and Yahoo! but this is an excellent update. Shows you don't have to redesign for the sake of it. Respect the past, keep what works, and shape it for today's tastes.

tl;dr - Focus. Boost signal, kill noise. Solve the first problem. Embrace uncertainty.

For how I got to that, a long-winded explanation below. Hope this helps!

https://medium.com/@nelson.taruc/designing-my-design-philosophy-a-10-year-case-study-98e2d1f4c1dc