To Figma, or not to Figma, that is the question. Basecamp's CTO David Heinemeier Hansson (AKA, DHH) wrote a blog post, Design for the web without Figma. Though I’m not a fanatic of the company formerly known as 37signals, I must say the Twitter outrage was excessive (see the tweet). This happened to Brian Chesky's comment at Config regarding about how Airbnb’s product managers became more like the function of product marketing. People heard that as, "get rid of product managers."

Do I think embracing the core elements of the periodic table of the web is important for designers? Yes. Do I think Figma is a drawing tool similar to how designers use Photoshop? Yes. Do I also think that Figma is a great tool and people should design in high fidelity? Yes. The answer is, "Yes. Yes. Yes." I'm not going to focus on what tools you should use. The hot take dialogs led to what I believe is a more interesting conversation, which is how design methods and processes are set up for value delivery. I’d like to expand on the five core areas I see: The value chain, materials of the output, company scale, tooling, and the production cycle.

1. Value chain

When deciding how to set up how work is done, the first aspect I look at is the value chain. What is the job to be done for the customer? How does the business deliver the value that results in success such as revenue? From there, map the value chain of what needs to get done. "Follow the money" is essentially following the value chain. Having a strong understanding of how your company delivers value to customers is the number one thing you should have mapped (at least in your head).

2. Materials of the output

If there was a periodic table of the product you are building, what would be on it? I studied art and our program was very cross-disciplinary. Even though I majored in drawing and painting, I had to take sculpture, wood design, ceramics, photography, jewelry and metal smithing, etc. I don't mean only pixels and code, but the constructs of that value chain. Much of the material output at replit is code because we are a software creation platform. This results in leaning in a lot of the software primitives as part of the value delivery in itself.

At One Medical, the product is an end-to-end, physical an digital, multi-device service. Our materials were supply chains, health inventory, provider availability, care quality, etc. Our teams created a lot of user flows and IA artifacts as much, if not more, than building digital interfaces. A button at One Medical invoked a complex workflow of business logic and operational workflows. The best artifacts to convey material in this case were diagrams before even coding digital interfaces.

3. Team/company scale

The answer is very simple if you work for yourself. You can do whatever you please, and that’s awesome (long live the indie developer). As you add more people to collaborate, it becomes more of a trade-off. At some point, it won't be your decision. Span of control is a term derived from management when it was focused on overseeing supply chains. Back then, goods were often physical goods designed, manufactured, and delivered to the customer. Today, the goods can be physical, digital, or a service of both; making the term span of control a bit dated.

The size of your team and company is a huge factor in how you scope your methods. What works for a two-person team is drastically different than a 200 person team. There is no right or wrong, only what is right for your company. The way an aircraft carrier operates is drastically different than a speedboat crew, and that's exactly how it should be.

4. Tooling

This is the one people debate perpeptually. A tool, at its core, is something (such as an instrument or apparatus) used in performing an operation or necessary in the practice of a vocation or profession. Based on the value you're delivering, materials you're constructing with, and the company/team scale, then think about tooling. As designers, we at times might get near sighted in our tools being what we use in order to concept, create, and build. However, how it funnels into the production cycle is also a consideration.

Understanding the right tool for the right job. Frank Lloyd Wright said it best: “You can use an eraser on the drafting table or a sledgehammer on the construction site.” As much as I love this quote, we should acknowledge that the cost of building software is not the same as a physical building (or is it?). There is a footprint with bandwidth and digital storage that often goes unacknowledged. Getting the concept right is key, and so is choosing the right tool to get the job done. Often tools used are excessive for the job is done. You could cut a cake with a machine gun, but a knife might be more appropriate.

I’m a huge advocate for designing in code and working with the raw materials. If designers are working in software, it’s a great skill to grow. However, there are times when it’s completely unnecessary. For example, if you’re working with a client or stakeholder and all they need is to visually see a flow of software functionality, coding it up is cutting a cake with a machine gun in this case. It’s excessive and unnecessary. Knowing what tools to use to get the job done is key.

5. Production cycle

It does not matter if you design in code if it’s a low comprehension artifact for your Sales and Marketing teams. Optimize for the work to move forward at a high quality. For example, Keynote is my slide deck authoring tool of choice. Despite that, I use Google Slides because people reviewing the work (such as Finance, GTM, and Executive) are in G Suite all day. Though I think Google Slides is subpar in an authoring experience, there is high comprehension in the people reviewing the material.

The way your company develops products and launches them is an invisible assembly line. Mapping this experience helps you spot where waste or flaws are happening. At One Medical, we used the Kaizen Cycle (continuous improvement) in both or physical and digital experiences. We’d spaghetti map what it took to deliver work, identify the waste, and make the improvements (active daily management).

Chesky’s talk at Config reminded me how young software design is compared to our predecessors. I’m sure thousands of years ago people had hot takes about architecture as well. People who are absolutist on certain methods are probably selling a book or workshop about it. This is great and it’s important to recognize that context and adapt it. 11-time NBA champion Phil Jackson (Chicago Bulls and Los Angeles Lakers) knew this lesson well. I can assure you the triangle offense was not ran the exact same way for Shaq as it was for Lucas Longley. It was adapted based on context. I’ve led five teams in my career. Though they have similar attributes and skills, none of them were run and operated in the exact same manner.

Do the same for how you build and ship. Rightsize your tools and methods.

Weekly recap

I’m back in the desert after nearly three weeks in San Francisco. The weekend. I'm looking forward to seeing Joey Chestnut defends his hot dog eating title and having an analog weekend. read and write. Excited to have an analog weekend.

Proof of Concept hits 150 issues
I didn’t realized until this week that this issue would be the 150th post! What started as a flakey newsletter has become one of the most consistent aspects of my life. I wanted to share the top issues from 100-150:

• Dynamic Interfaces: Part Un, Deux, and Trois¹

• Why brand designers make great product designers

• Early company building

• The role of taste (and what it means)

• The ambition of Prometheus

• Individual point of view and collaboration

• Drawing is the most enduring skill

• A primer on startup advising

• Parallel paths

• Enter Dynamic Island, a major hint at Apple's Extended Reality (XR) strategy

Goodbye, Tweet of the week
I'm going to stop posting a tweet of the week. The primary reason is now that Twitter is limiting its API, it's too much effort to curate it. Twitter used to allow Substack to embed tweets, which was awesome. That's no longer available and poet.so, the service I loved using, no longer works because of the API limitations. #RIPTweetOfTheWeek

Config Recap
I'm too tired to write a in-depth Config recap. It was awesome. Here's a few newsletters and posts I enjoyed about Config and what Figma announced:

• Joey Banks's Baseline

• Keith Armstrong's The Div Dive

Note: Dan Mall and Femke van Schoonhoven wrote great recaps and I suggest you subscribe to their newsletters (I have no clue how to link to the specific post!)

Hype links

• Your Professional Decline is Coming (Much) Sooner Than You Think

• A great plugin by Yann-Edern Gillet: Styles to Variables

• Metamuse Podcast's 81st episode is with Obsidian CEO Stephan Ango

Job board

• Replit is hiring a Product Manager for AI

• Stripe is hiring a Head of Design, Consumer Products (Go work for Katie Dill!)

• Atlassian is hiring a Head of Design for Growth

• Stitch Fix is hiring a VP of Product and Design