{30} Problem Validation, Design Specs & Gradient Borders
Featuring Jen Abel, Vitaly Friedman, Cory House, Yanko Valera, Shripal Soni, and Chris Sev
Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.
Product: Problem Validation
Jen Abel
![Twitter avatar for @jjen_abel](https://substackcdn.com/image/twitter_name/w_96/jjen_abel.jpg)
This is an important distinction. I’ve seen a lot of pitfalls from companies seeking product validation. It’s easy to ask a friend if a solution is good and get a false positive from someone offering words of encouragement.
You are less likely to get a false positive when asking if someone is experiencing a problem. It’s a less personal, more rational thought experiment.
It’s also important to appreciate the fact that your initial solution is likely to be garbage. Not always, sometimes companies hit the lotto on their v1. It is much more common that your v1 is suboptimal, and you get closer to a more optimal solution after many rounds of improvements.
So I agree. Early conversations should focus on validating the problem. It’s ok to also talk about solutions. That’s part of the improvement process. But validate problems, not solutions.
Figma: Design Specs
Vitaly Friedman
![Twitter avatar for @vitalyf](https://substackcdn.com/image/twitter_name/w_96/vitalyf.jpg)
![Image](https://substackcdn.com/image/fetch/w_600,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fpbs.substack.com%2Fmedia%2FFpeSO2yWcAEW7_V.jpg)
This is a neat tool. A lot of teams could produce better results with something like this.
I often worry about silo’ing the dev and design teams and essentially making the design team manage the dev team. I’ve always hated workflows that involve a non-collaborative spec handoff where design becomes a bottleneck for every change. This tool in those environments could get ugly.
If used in a healthier workflow involving a non-blocking design system, I see this helping a team get closer to pixel perfection without jamming the gears.
GraphQL: Network Inspector
Cory House & Yanko Valera
![Twitter avatar for @housecor](https://substackcdn.com/image/twitter_name/w_96/housecor.jpg)
![Image](https://substackcdn.com/image/fetch/w_600,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fpbs.substack.com%2Fmedia%2FFpa7A3_aQAI1hvs.png)
This has been one of my frustrations in troubleshooting GraphQL. Digging into GraphQL requests on the network tab in Chrome is tedious and very unintuitive. A simple extension to help name and organize requests can be life-changing.
CSS: Gradient Borders
Shripal Soni
This is a wonderful technique that can produce a beautiful gradient border in a few lines of code. Producing an effect like this used to involve a very ugly hack involving a bunch of images and some messy markup. It would have been difficult to pull off the 45deg gradient.
Discretion is advised: Old School CSS Round Corners
CSS: Tailwind Apply
Chris Sev
![Twitter avatar for @chris__sev](https://substackcdn.com/image/twitter_name/w_96/chris__sev.jpg)
I seem to be in the minority on the Tailwind ‘apply’ debate. I don’t find the large acronym blobs to be visually parsable. The aversion to naming things in the Tailwind community is a little confusing. If you want someone to read your code and understand what the hell is going on, take the time to name things. Using ‘apply’ is much more semantic.
I do agree with Chris that JS components are an acceptable solution. The acronym blobs still live in components, but pages/views/layouts are much more readable.