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.
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.
The only person who wants a carousel on your site is you. That’s it. It’s a self-serving vanity project so that you can showcase all of your babies at the same time without telling the world which one is your favorite.
This is an excellent framing for minimal viable products—what would the black box theatre production be?
Forget about all the production and complexity you could build. What’s the purpose you want to convey at the core?
I worry that more and more nowadays, people jump to JavaScript frameworks because that is what they know or have been taught, even though they are entirely inappropriate for a wide array of things and can often produce poor results.
Last week I wrote about the great work that Matthew did and now he’s written up his process:
The important thing is to have a resilient base layer of HTML and CSS, and then to enhance that with JavaScript.
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Designing your design process:
- Know your strengths and focus resources on your weaknesses.
- Learn to identify the immovable objects.
- What has to be perfect now and what can be fixed later?
Shots fired!
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
Focusing on the median or average is the equivalent of walking around with a pair of blinders on. We’re limiting our perspective and, in the process, missing out on so much crucial detail. By definition, when we make improving the median or average our goal, we are focusing on optimizing for only about half of our sessions.
Tim does the numbers…
By honing in on the 90th—or 95th or similar—we ensure those weaknesses don’t get ignored. Our goal is to optimize the performance of our site for the majority of our users—not just a small subset of them.
It really, really bothers me that wireframes have evolved from being a prioritisation tool into a layout tool (disempowering UI designers in the process), so I’m happy to see an alternative like this—somewhat like Dan Brown’s Page Description Diagrams.
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
Andy points one of the potential pitfalls in linearising your content for small screens.