The value of design principles done right:
What I’ve learnt is that principles are not a luxury. Making explicit and conscious what drives your behaviour can be incredibly powerful as a means to critically shape a team and organisation to be who they want to be.
On leaving the company, Hixie compares the Google of old to what it has become today:
Google’s culture eroded. Decisions went from being made for the benefit of users, to the benefit of Google, to the benefit of whoever was making the decision. Transparency evaporated. Where previously I would eagerly attend every company-wide meeting to learn what was happening, I found myself now able to predict the answers executives would give word for word. Today, I don’t know anyone at Google who could explain what Google’s vision is. Morale is at an all-time low. If you talk to therapists in the bay area, they will tell you all their Google clients are unhappy with Google.
I agree with everything that Matt says here. Evangelising accessibility by extolling the business benefits might be a good strategy for dealing with psychopaths, but it’s a lousy way to convince most humans.
The moment you frame the case for any kind of inclusion or equity around the money an organization stands to gain (or save), you have already lost. What you have done is turn a moral case, one where you have the high ground, into an economic one, where, unless you have an MBA in your pocket, you are hopelessly out of your depth.
If you win a business-case argument, the users you wanted to benefit are no longer your north star. It’s money.
Vitaly provides some sensible rebuttals.
This may mark the beginning of Gov.uk’s decline. The top-listed priorities are the very antithesis of starting with user needs. Instead from now on it’s going to be about growth, shiny new technology, having a native app, and literally pivoting to video.
It’ll be interesting to see if they try to maintain their existing design principles while simultaneously abandoning them.
I’ve spent a lot of time thinking, talking and writing about evaluating technology and what Robin describes here is definitely a bad “code smell” that should ring alarm bells:
What’s really concerning is when everyone is consumed with the technology-first and the problem-last.
Unless you’re working in an R’n’D lab, start with user needs.
I’m certain now that if you want to build something great you have to see through the tech. And that’s really hard to do when this cool new thing is all that anyone is talking about. But that’s why this one specific thing is the hallmark of a great organization; they aren’t distracted by short-lived trends and instead focus on the problem-first. Relentlessly, through the noise.
I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
This is an oldie from Julie Zhou, but it’s a timeless message about the value of good (i.e. actually useful) design principles.
See also what she said on this podcast episode:
When push comes to shove and you have to make a trade off, how are you, in those moments, as a team or a company going to prioritize? What are you going to care about the most? Good values will be controversial in that respect because it’s something that another company might have made a different decision than you.
Carolina’s post reminds me of A Paradise Built In Hell by Rebecca Solnit:
In the face of disaster, survivors get together, make time and help one another regardless of their differences. It is beautiful and inspiring.
The quest for more is a kind of prison that we make for ourselves. The idea that if we work ourselves to the bone now we can live a better life later is a convenient lie that we’ve been conditioned to tell ourselves.
An open and honest post from Ben.
I see decentralization as a way to lead to a more equitable society through disassembling existing hierarchies, for example, but I see straight through the people who see these ideas as a way to build a new hierarchy for their own benefit. We used to talk about abolishing gatekeepers in the early days of the web, too, until it became clear that many people just wanted to become a new kind of gatekeeper themselves.
I was really chuffed to see some posts of mine referenced in this rather excellent piece about design principles for front-end development.
The idea that your job should be the primary source of meaning in your life is an elaborately made trap, propped up across industries, designed to make you a loyal worker who uses the bulk of their intellectual and creative capacity to further their own career.
I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:
- Browser diversity keeps the Web deliberately slow
- Browser diversity fosters consensus and cooperation over corporate rule
RFC 8890 maybe the closest thing we’ve got to a Hippocratic oath right now.
A community that agrees to principles that are informed by shared values can use them to navigate hard decisions.
Many discussions influenced this document, both inside and outside of the IETF and IAB. In particular, Edward Snowden’s comments regarding the priority of end users at IETF 93 and the HTML5 Priority of Constituencies were both influential.
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
There is a huge world out there where design isn’t embraced, where designers are clawing for resources, and where design isn’t prioritized. Most of the organizations that are changing your world don’t know much about design, aren’t looking for designers, and won’t even understand what designers are talking about when they show up at the front door.
Garrett’s observation is spot-on here:
I’ve been trying to understand the appeal of these frameworks by giving them an objective chance. I’ve expanded my knowledge of JavaScript and tried to give them the benefit of the doubt. They do have their places, but the only explanation I can come up with is that developers are taking a similar approach as Ruby and focusing on developer convenience and productivity. Only, instead of Ruby’s performance being tied to the CPU level, JavaScript frameworks push the performance burden to the client.
In both cases, the tradeoff happens in the name of developer happiness and productivity, but the strategies have entirely different consequences. With Ruby, the CPU is still (mostly) the responsibility of the development team, and it can be upgraded. With JavaScript, the page weight becomes an externality pushed onto visitors.
Let us not overlook the fact that a semantic HTML web site is inherently accessible by default. When we bend the web to our will, we break that. So we have a responsibility to correct it. Sure the new technologies are neat, but the end result is usually garbage. This all requires some next-level narcissism that our goals and priorities as developers are far more important than that of the audience we’re theoretically building software to serve.