Hive's Design Principles
blog.hive.com
blog.hive.com
I think if you are building a simple tool to solve a simple problem, this makes sense.
On the other hand, I think this gets abused in the other direction: by designers using this as an excuse to not think about flexibility, or engage in humility. It's like the misuse of premature optimsation, but for designers.
For example, I think it's instructive that almost[1] none of the popular pro tools in any industry follow this guideline. Those tools are not for easing users in, they are for getting shit done: they understand that the idea that some UX designer can come along and tell the entire photography world how to process raw files, or tell developers how to build software in N different languages, or what a film editor's process should be for making movies etc, is utter druff.
This is why, as I understand it, the film industry reacted to strongly and negatively to Final Cut X: Apple were saying "we don't care what your current process is, you must now edit films this way, in this order, using this process, because we know better".
[1] I wanted to just say "none" here, but I obviously haven't used all pro tools
1) It clutters the user experience
2) App designers are benevolent gods that keep users from self-harm
Now 1) I can understand, though in that case I prefer something like Overcast, where the settings menu has a submenu called "Nitpicky Details", for those of us who really care. 2) seems to be a prevalent opinion in the business these days -- while it makes sense for security on mobile devices (no root access etc), a lot of times it's just pure conceit IMHO.
Don't guess what they want to do (Predictable) and leave it Open; yet you know what they should do and don't give them an option (Opinionated).
And
Don't surprise them (Predictable); yet surprise them (Delight)
Yes. Open source does not get this at all.
Don't make the easy things hard. Make the usual case the default, without any action needed by the user. But it won't always be what the user wants, so give them the option.
Of course, some open source projects do have this philosophy, and when they start removing options, I switch to something else. GNOME is a good example. I wish the current version of Nautilus (GNOME Files?) had half the options of the file managers that forked from earlier versions of Nautilus (Nemo and Caja,) because I actually use those options.
How useful would hammers be if they ONLY drove nails?
Here's a Slack example of this. We moved from HipChat to Slack and two of the "options" we as a team dearly miss are:
1. Being able to set a status that reflects what we're doing if unable to chat for the time being, not just a binary online or away. Now I have to inform the team I'm on a conf call or will "brb - making lunch" in a chat room which distracts everyone. HipChat was pretty flexible that way, it's a small thing, but for our team hugely important, especially for remote workers.
2. Being able to specify how long I'm AFK before setting me to "Away". Sometimes I take calls on my mobile (we have apps for our internal SIP/asterisk stuff) and I like to wander around when chatting because it stretches my legs. But I find annoying that on longer calls Slack assumes after 30 mins of no activity I'm "Away" and "grey blobs" me making it look like I'm completely offline. Unfortunately the "Snooze notifications" don't cut it because it still doesn't let me convey, at-a-glance, why I'm deferring your messages.
From googling around it seems these are common gripes that Slack don't see as a priority to fix.
Don't get me wrong, there's a lot of things Slack does well, but as paying customers, not addressing these two issues causes some low level resentment.
We're officially out of names :(
> Hive’s 7 Design Principles
They are Hives design principals. Not necessarily for everyone.