notes on the art of right-sizing
how do you know if something is too big or too small?
Hellooooo everyone,
I recently watched designer-technologist Evan You’s technical talk on the design principles of VueJS, a “hipster” UI rendering library. If I could give this talk a name, I’d call it The Art of Right-Sizing. How do you make something not too big, not too small, but just right?
Right-sizing is some of the most complicated and psychologically draining work we do in our professional and personal lives. And often we don’t even realize that’s the bulk of what we do. So there are a lot of nuggets of wisdom here.
For the sake of saving you some time, I’ll summarize the talk below.
What I’m Thinking About
Getting something just right is about tradeoffs — what do you gain and give up by making certain choices? It’s not so much about correctness as it is about feel.
And tradeoffs are concerned with understanding audience and use cases. Who is using it and what are they using it for?
VueJS’s audience:
HTML/CSS beginners
Hobbyists and tinkerers
Veterans coming from other libraries
Architects making high-level decisions for their team
Nontechnical stakeholders seeking to innovate on behalf of their organization
VueJS’s use cases:
Sprinkle the library into an existing system
Start from scratch on a small project
Grow the project to a medium size and minimal complexity
Scale it to a large team with many people moving in and out of the project over time
These two dimensions form a matrix of tradeoffs.
If the design of the library panders to beginners, then doing more complex things gets hacky and hard to understand. If every requested feature is supported, then things get bloated and it’s hard to figure out how to go about using the tool.
So how do we design anything tastefully? How do we build something that is friendly enough to newcomers but also grows up and grows old with you?
Evan You answers this fundamental question by describing a few dichotomies he struggles to resolve.
1/4 Approachability vs. Scalability
Approachability brings great value when you have limited resources. You can get started and build momentum without investing a lot of time and energy. But as your work gets more complex, you may start hitting an upper limit to what you can do.
Scalability allows you to keep building. You don’t have to throw away all your prior work. However, there is a steep learning curve that you need to survive. And why suffer through that curve if you’re still in an exploratory stage?
Example: the $50 Prince tennis racquet you bought for your kid vs the $200 Wilson Pro Staff that Roger Federer uses.
2/4 Configuration vs. Composition
The “Configuration” approach decides upfront on the right way to do things. Execute on the fundamentals extremely well, set good defaults, and expose the ability to customize.
The “Composition” approach, however, allows you to create and scale new possibilities. Given a small set of interoperable tools, an inventive user can build pretty much whatever he can imagine.
Example: Dishwasher vs. Soap + Sponge + Rack
3/4 Existing Language vs. New Language
You lower the barrier to entry by choosing an existing language that is widely used. Users are already trying to learn how to use your tool — why make them wrap their heads around new concepts and terminology, too?
But a new language might possess better concepts and terminology. It might help users make better sense of what they are doing (and also what is possible).
Example: Jhumpa Lahiri — “I am a tougher, freer writer in Italian”
4/4 Large-Scope Coherence vs. Small-Scope Flexibility
Conceptual cathedrals centralize the problem-solving process. The designer builds in all the abstractions necessary. They are grand, majestic, ambitious, and awe-inspiring.
But cathedrals take more time to figure out because there’s just so much to take in. They are inflexible — the built-in tools may not fit what you’re using them for. There’s a larger maintenance surface — new ideas have higher costs because adding new things takes more effort.
In contrast, we can build bazaars. There are fewer concepts needed to get started, more flexibility to explore new ideas and try new things. We build vendor stands and alleyways. With these primitives, we push invention to the users. They discover new and great ways to do things.
However, as the bazaar grows, tribal knowledge becomes semi-required undocumented knowledge. Some ways of doing things will be better than others, but you’ll have to learn those patterns yourself. The ecosystem can grow too fast and become fragmented.
These four dichotomies are the ground for what Evan You calls “progressive scope.” When you build anything, you are thinking not just about what it is now, but also what it will become. You are not just thinking about what the tool will be, but also about what the tool-user will do.
As a result, the art of right-sizing is a very individual, opinionated, and idiosyncratic effort. There is no single correct way of doing it. But the only thing it cannot be is “one size fits all.” You have to decide what is important and allow those principles to discover carve a path.
Bullet-Point Summaries
Million-Dollar, One Person Businesses
Code, distribution, and manufacturing are being commoditized.
Build wealth by focusing on what is scarce.
Develop high-leverage skills.
Start with services to find valuable problems.
Automate, outsource or delegate non-core competencies.
Don’t be the best. Be the only. Find your niche.
Have a great week! I’ll drop you a note same time next week.
Ammar