I enjoyed chatting to Larry Botha on the Fixate On Code podcast—I hope you’ll enjoy hearing it.
Thursday, February 8th, 2018
Saturday, January 20th, 2018
Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn’t provide mobile interface.
Given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.
It’s true that this often means doing more work. That’s why it’s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We’re supposed to be saving them time, not passing it along.
I’ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
Now I’m wondering if I should’ve clarified that second step further. When I talk about choosing “the simplest possible technology”, what I mean is “the simplest possible technology for the user”, not “the simplest possible technology for the developer.”
Time and time again, I see decisions that favour developer convenience over user needs. Don’t get me wrong—as a developer, I absolutely want developer convenience …but not at the expense of user needs.
I know that “empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, “This tech stack is best option for our team”, or “This solution is the best for the widest range of users.” Then, given the choice, favour user needs in the decision-making process.
There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that’s okay, as long as we acknowledge that compromise and strive to do better next time.
But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.
That doesn’t mean we must become hairshirt-wearing martyrs; developer convenience is important …but not as important as user needs. Start with user needs.
Tuesday, January 16th, 2018
- Fitts’s Law
- Hick’s Law
- Jakob’s Law
- Law of Prägnanz
- Law of Proximity
- Miller’s Law
- Parkinson’s Law
- Serial Position Effect
- Tesler’s Law
- Van Restorff Effect
- Murphy’s Law
- Sturgeon’s Law
Friday, December 8th, 2017
Collections of design principles that you can contribute to.
The aim of the site is to help us analyse what good Design Principles are. How Design Principles are created and measured. How they develop.
Sunday, December 3rd, 2017
Monday, November 27th, 2017
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
Wednesday, November 15th, 2017
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.
These are really good ideas for evaluating design principles. In fact, I would go so far as to say they are design principles for design principles.
- Good design principles are memorable
- Good design principles help you say no.
- Good design principles aren’t truisms.
- Good design principles are applicable.
Monday, October 23rd, 2017
I love what Ben is doing with this single-serving site (similar to my design principles collection)—it’s a collection of handy links and resources around voice UI:
Designing a voice interface? Here’s a useful list of lists: as many guiding principles as we could find, all in one place. List compiled and edited by Ben Sauer @bensauer.
BONUS ITEM: Have him run a voice workshop for you!
Monday, October 9th, 2017
All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
Friday, September 29th, 2017
This is a fascinating exercise—take a good set of design principles and test them for reversibility. The results are entirely plausible.
I’ve taken this exercise to the extreme. The philosophy behind inclusive design is that the thing you create works for everybody, no matter the context. The idea behind this experiment in Exclusive Design is that you design something for one specific person, in a controlled environment, in a specific context. Tailor made.
Maybe I should add these to my collection.
- Provide a unique experience
- Ignore situation
- Be inconsistent/innovative
- Take control
- Offer the best possible solution
- Prioritise identity
- Add nonsense
Wednesday, September 6th, 2017
I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.
Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.
These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.
Sunday, August 20th, 2017
I like this list:
This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project.
I’ve added them to my collection of design principles.
Sunday, August 6th, 2017
A series of questions to ask on any design project:
- What are my lenses?
- Am I just confirming my assumptions, or am I challenging them?
- What details here are unfair? Unverified? Unused?
- Am I holding onto something that I need to let go of?
- What’s here that I designed for me? What’s here that I designed for other people?
- What would the world look like if my assumptions were wrong?
- Who might disagree with what I’m designing?
- Who might be impacted by what I’m designing?
- What do I believe?
- Who’s someone I’m nervous to talk to about this?
- Is my audience open to change?
- What am I challenging as I create this?
- How can I reframe a mistake in a way that helps me learn?
- How does my approach to this problem today compare to how I might have approached this one year ago?
- If I could learn one thing to help me on this project, what would that one thing be?
- Do I need to slow down?
Thursday, June 22nd, 2017
Analysing what the web is. It’s not the technology stack.
To count as being part of the web, your app or page must:
- Be linkable, and
- Allow any client to access it.
I think that’s a pretty good definition.
Mind you, I think this is a bit rich in an article published on The Verge:
The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.
Still, we can agree on this:
Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.
Friday, June 9th, 2017
Monday, June 5th, 2017
eLife goes live
The World Wide Web was forged in the crucible of science. Tim Berners-Lee was working at CERN, the European Centre for Nuclear Research, a remarkable place where the pursuit of knowledge—rather than the pursuit of profit—is the driving force.
I often wonder whether the web as we know it—an open, decentralised system—could’ve been born anywhere else. These days it’s easy to focus on the success stories of the web in the worlds of commerce and social networking, but I still find there’s something that really “clicks” with the web and the science (Zooniverse being a classic example).
At Clearleft we’ve been lucky enough to work on science-driven projects like the Wellcome Library and the Wellcome Trust. It’s incredibly rewarding to work on projects where the bottom line is measured in knowledge-sharing rather than moolah. So when we were approached by eLife to help them with an upcoming redesign, we jumped at the chance.
We usually help organisations through our expertise in user-centred design, but in this case the design and UX were already in hand. The challenge was in the implementation. The team at eLife knew that they wanted a modular pattern library to keep their front-end components documented and easily reusable. Given Clearleft’s extensive experience with building pattern libraries, this was a match made in heaven (or whatever the scientific non-theistic equivalent of heaven is).
A group of us travelled up from Brighton to Cambridge to kick things off with a workshop. Before diving into code, it was important to set out the aims for the redesign, and figure out how a pattern library could best support those aims.
Right away, I was struck by the great working relationship between design and front-end development within eLife—there was a great collaborative spirit to the endeavour.
Some goals for the redesign soon emerged:
- Promote the HTML reading experience as a 1st choice for readers.
- Align the online experience with the eLife visual identity.
That led to some design principles:
- Focus on content not site furniture.
- Remove visual clutter and provide no more than the user needs at any stage of the experience.
- Aid discovery of value added content beyond the manuscript.
Those design principles then informed the front-end development process. Together we came up with a priority of concerns:
- Taking advantage of browser capabilities
- Visual appeal
It’s interesting that maintainability was such a high priority that it superseded even performance, but we also proposed a hypothesis at the same time:
Maintainability doesn’t negatively impact performance.
The combination of the design principles and priorities led us to formulate approaches that could be used throughout the project:
- Progressive enhancement.
- Small-screen first responsive images.
- Only add libraries as needed.
Then we dived into the tech stack: build tools, version control approaches, and naming methodologies. BEM was the winner there.
None of those decisions were set in stone, but they really helped to build a solid foundation for the work ahead. Graham camped out in Cambridge for a while, embedding himself in the team there as they began the process of identifying, naming, and building the components.
The work continued after Clearleft’s involvement wrapped up, and I’m happy to say that it all paid off. The new eLife site has just gone live. It’s looking—and performing—beautifully.
What a great combination: the best of the web and the best of science!
eLife is a non-profit organisation inspired by research funders and led by scientists. Our mission is to help scientists accelerate discovery by operating a platform for research communication that encourages and recognises the most responsible behaviours in science.
Tuesday, March 14th, 2017
Ellen goes through the principles behind the tone of voice on the new Clearleft site:
- Our clients are the heroes and heroines, we facilitate their journey.
- Speak as an individual doing whatever it is you love. Expose lovable details.
- Use the imperative, kill the “-ing”.
- Be evocative and paint the picture. Show don’t tell.
- Be a practical friend.
- Be inquisitive. Ask smart questions that need solving.
Thursday, February 16th, 2017
Some proposed design principles for web developers:
- Focus on the User
- Focus on Quality
- Keep It Simple
- Think Long-Term (and Beware of Fads)
- Don’t Repeat Yourself (aka One Cannot Not Maintain)
- Code Responsibly
- Know Your Field
Monday, December 19th, 2016
The styleguide, design principles, and pattern library for British Airways. It’s the “global experience language” for BA …so it’s called BAgel.