This is a great point. "Principles" should be about taking a stand about the trade-offs between two desirable things. They can then be used to help guide you when these things come into conflict. Who is trying to make a product that is intolerant, burdensome, aloof, and inconsistent?
A framework I usually use is a "this over that", where both "this" and "that" represent things generally considered "good". The Agile Manifesto contains a brilliant example of this:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Notice how everything on the right is also a "good" thing, but the manifesto is making you CHOOSE.
I've seen #1 used many times to solve the problem of "too many regressions" with "the team just needs to communicate more" or "we should set up regular meetings to deal with this issue".
It was hard to argue that those teams weren't following both the message and spirit of the agile manifesto, as individuals and interactions were plainly taking precedence over tools and processes.
It doesn't, after all, say "individuals and interactions over tools and processes, except when tools and processes make more sense".
I think the proper understanding of those principles is "when in doubt, choose this over that", and not "always choose this over that".
That said, the problem you described isn't really with the manifesto, but with people refusing to use common sense - or even more likely, with incentives within the organization being so aligned that decisionmakers benefit from making bad calls. It's something that happens surprisingly often.
>I think the proper understanding of those principles is "when in doubt, choose this over that", and not "always choose this over that".
That's exactly how the teams I worked with applied it. They were in doubt and they decided on individuals and interactions.
>That said, the problem you described isn't really with the manifesto, but with people refusing to use common sense
It absolutely is a problem with the manifesto and it isn't a common sense decision.
Expending a not insignificant level of resources on automated regression testing and CI, or indeed, any other kind of tooling or process is far from a common sense decision - it's a pretty delicate trade off, in fact. Some tooling is worth it, some isn't.
If the manifesto said "think carefully about tooling and recognize the delicate trade offs involved" then maybe the problem wouldn't be with the manifesto. It doesn't. It says "individuals and interactions over tools and processes". Ergo meetings > tools.
No. Unfortunately, much of the design industry's exports as of late have become by-and-large impractical fluff. I say this as a designer. If these ideas were expanded upon and articulated with case studies or practical advice then absolutely.
If you're curious about principles backed with implementation details, check out https://cadence.cc. Looks unassuming but one of the best books on design I've ever read.
Designer here as well, similarly frustrated with the lack of analytical rigor in the discipline.
Cadence & Slang did not impress me. I read it a few years ago now so I can’t quote exact examples, but at the time it felt like more fluff to be honest. Well written fluff, but still fluff (ie will design students in 20 years, or even now, benefit from reading it like they would a classic such as “Grid systems for visual design”? My money is on no). Would be curious to hear what aspects of it you particularly enjoyed.
Sadly enough, I find that the best books on designing for interactive media are from the 80s/90s. Examples include Raskin’s “The Humane Interface”, Togazzini’s compendiums, etc.
I do design research. My papers always provide principles with examples and evidence. They are generally very specific though (unlike this article). I agree that it is rare outside of the research community to find evidence (the why) and implementation details (the how) though.
An example paper of mine:
Toward Principles for the Design of Navigation Affordances in Code Editors: An Empirical Investigation http://dl.acm.org/authorize?N37917
>I do design research. My papers always provide principles with examples and evidence.
From what I remember of studying Human Computer Interaction (HCI) as an undergrad in the 90s, the evidence was derived from learnability studies. This meant that research favoured point and click interfaces (which are the equivalent of caveperson grunting, IMO) over command line interfaces which allow much deeper expressivity. There was basically no affordance to systems that people use day-in day-out and are happy with the trade offs in the learning curve (vi, emacs, blender, lighting desks, audio controllers, Bloomberg terminal).
I like that your example paper is about trying out different interactions in a small part of a daily-driver piece of software. But it's still trying a 'new' thing for some of the experimental users which means learnability is core. How do you manage the balance?
There are a few human-computer interaction conference proceedings that I would recommend.
CHI is the biggest and most prestigious, but also most general. It will include a lot of irrelevant papers too. UIST is smaller and focuses on novel interactions. CSCW is about collaboration. IUI is about intelligent user interfaces. VLHCC publishes work on developer tools from a human perspective.
The easiest way to find these papers is through scholar.google.com. Just search for what topic you want, and it will try to find relevant research papers.
CHI, UIST, CSCW, and TEI are my personal favorite academic conferences for interactive media related design. (The paper posted by GP was published at CHI)
Hadn't heard of The Humane Interface, I'll have to check it out :)
Re: C&C, a couple of things (just picking from my highlights).
Chapter 2 - Consistency & Character
This informed my own work quite a bit. Especially notes about how consistency aids clarity in the product. Also nice "hmm, now there's an idea" type of stuff like "a designer creates an architecture of information within the mind of the recipient of his work." This triggered a bit of a waterfall, leading to stuff like reading Christopher Alexander's _Notes on the Synthesis of Form_.
Also from this chapter is the point about how having a consistent behavioral language. Meaning, if two elements perform similar tasks, they should look similar to one another.
Lots of great little beats like this that have wedged themselves into my thinking.
Chapter 3 - Simplicity
The one about only forcing a user to create an account when it provides value really informed my ability to design solid onboarding experiences. Taught me to build gradually invasive products that speak to the user like you would a new acquaintance. Over time, you slowly get comfortable asking them for more and more (e.g., use things like local storage to persist data temporarily to give the feel of hitting a DB).
---
Man, is there a place to talk about stuff like this? You got my hamsters spinning.
"Tolerant: Handle errors respectfully.
Effortless: Don’t make demands or place restrictions on your users.
Accommodating: Be approachable, uncluttered and give people room to manoeuvre.
Consistent: Follow standards, guidelines, conventions and best practices."