Design systems, systems thinking, and the "curse of the gifted"

A friend of mine calls it "the curse of the gifted" -- a tendency to lean on your native ability too much, because you've always been rewarded for doing that and self-discipline would take actual work.

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself.  As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals *must* develop in order to handle the kind of problem complexity you eat for breakfast.

But you make some of your more senior colleagues nervous.  See, we've seen the curse of the gifted before.  Some of us were those kids in college.  We learned the hard way that the bill always comes due -- the scale of the problems always increases to a point where your native talent alone doesn't cut it any more.  The smarter you are, the longer it takes to hit that crunch point -- and the harder the adjustment when you finally do.  And we can see that *you*, poor damn genius that you are, are cruising for a serious bruising.

As Linux grows, there will come a time when your raw talent is not enough.  What happens then will depend on how much discipline about coding and release practices and fastidiousness about clean design you developed *before* you needed it, back when your talent was sufficient to let you get away without.

http://lwn.net/2000/0824/a/esr-sharing.php3

How Linus Torvalds works (as written in this post) is how I cook. ;) I don't measure, I eyeball everything. I do things until they "look right" and then I stop.

I would never ever ever do that fast, loose, play-it-by-eye-and-natural-talent with a design system, because I have learned that it just doesn't scale. In fact, I design... design systems specifically to avoid or mitigate the "curse of the gifted".

At the end of the day, a design system that isn't easy enough to use by all involved in the SDLC, so much so that it becomes the default pit of success that teams fall into together... is a failed design system. Or one that is currently failing, at any rate. Failures can be remedied, so there is that.

I see a disturbing tendency to approach design systems (especially for enterprise) with far too much reliance on 'the curse of the gifted'. This is especially evident when every piece of a design system is designed on an ad-hoc basis, with no regard to how it fits into everything else. If the designer's eye is good enough, they can skate by on the curse of the gifted - until they cannot, anymore. And their teams? God help their teams. 

When it comes to design systems - I want the opposite of skating by on talent. I want to help build design systems that enable delivery teams to fall into the pit of success together. The kinds of systems that improve collaboration for everyone, because of a clear, shared understanding of what it is we want to do, and what we have on hand to do it. Design systems where the default is usually the right choice, where guesswork is kept to a minimum... and yet where necessary changes can be made on the fly with the minimum of cost, or drama. And while I'm describing my ideal pony, I want to be able to stay and see such a system grow and evolve over time.

Right now, I'm still looking for that pony. Maybe I'll get lucky. ;)

Common-sense rules-of-the-thumb for designing software that makes sense

Excerpts from a JIRA article I wrote at work.

Make system status and feedback clear and visible
Use status mechanisms to keep users aware and informed via appropriate feedback, and within a reasonable timeframe. Status information should be up-to-date and easy to spot.

Present information with meaningful aids to interpretation
Use words, phrases and concepts familiar to users - don't use 'programmer speak'. Use everyday terms, or familiar frameworks.    

Help users recognise, diagnose and recover from or resolve errors
Give users a "way out" when they make mistakes (e.g. cancel). Where Undo/Redo is not possible or viable, present users with solutions.
E.g. The supplier record could not be deleted because transactions have been made against it. <Deactivate Supplier Record> <Cancel>

Use clear, consistent language, and names/labels that are conceptually related to their functions
Standardise language across your platform. If 'Cancel' means 'Exit without implementing any changes' in one context, it should mean that in all contexts. Whenever possible, button labels should be specific, rather than generic. (e.g. 'Save & Exit' vs 'Okay').   

Help users not to make mistakes
Present users with a confirmation before they commit to an action with serious and/or irrevocable consequences. In such cases, it's a good idea to place the Commit and Cancel buttons far apart to prevent users clicking the wrong buttons by mistake. If keyboard controls are in play, require the users to either click the (far apart) buttons, or to commit by pressing a specific key or key combination, rather than tab-Entering.

Display only the information a user needs to complete a discrete task at a given time
Don't make users remember information from one part of the dialogue to another, and don't pepper them with information irrelevant to the task at hand.

Make the right things invisible
Automate and/or hide tasks/functions users have no control over, but that the platform requires to work.  

Group information consistently and meaningfully
Don't make users search and mix-n-match information from all over your page if what they're looking for falls into an identifiable group. (E.g. Address, Mobile, Fax..)   

Reduce user workload & set meaningful defaults
Pre-populate standard fields whenever possible and/or helpful. Base defaults on choices that the majority of users would make. Default settings should make things easier on the standard user, not harder.

Notes:
This list was based on Jakob Nielsen's heuristics as published in Usability Engineering, Jill Gerhardt-Powals' work in Human Computer Interaction (paid link), and Bruce Tognazzini's First Principles of Interaction Design.

Browse vs. Search: Which Deserves to Go?

While every engineer may find Search easy and efficient, that is not the experience of most people under many conditions, including those encountered by the users of the systems Craig has referenced—Contacts, iOS, and Lion. Learning to type into a box is easy. Memorizing the names of perhaps several hundred apps so you know what to type into the box, not so easy. Unless you are an engineer.
 Graphic designers, left unchecked and unschooled, are likely to aim for maximum visual simplicity at the expense of both learnability and usability. Such interfaces require users to discover new capabilities by clicking around and seeing what happens. Users don't do that. 
via asktog.com

So much good stuff in here! The second quote about graphic designers, in particular, sounds like what I spent the first 3+ years when I started working in the digital space arguing against, usually on the losing side.

What We've Learned About Responsive Design - Newfangled

Responsive design is more work. And more expensive. Maybe you don't need it as much as you think you do.

I've run into the idea that since responsive design is a more efficient mobile solution than creating unique mobile sites or alternate page templates, it is therefore going to be cheaper and simpler than what everyone is expecting. Not true. The fact of the matter is that doing responsive design requires work that just wouldn't be done at all if mobile wasn't a consideration. Now, I'm not advocating that we ignore mobile. But in some cases, I'd argue that mobile is probably higher on the priority list than a serious cost/benefit analysis would merit.

Our audience is primarily comprised of people working in the advertising, marketing and design industry. They're people who influence or make decisions about design and development projects. With our audience in mind, if you were to ask me if mobile should be a higher priority I'd say absolutely. I'd think of all of our hip and stylish visitors and how many of them probably already have an iPhone 5. But you know what? In the last month, just under 10% of our website's visitors accessed it with a mobile device. That includes phones and tablets. If I extend my look to the last six months, the mobile population is exactly the same. The last year? It drops to 8%. So, mobile traffic is growing, but not as rapidly as I would have assumed based upon what I think I know about our audience. With those numbers, should mobile be prioritized as much as it has been (we're about to launch a site redesign that makes heavy use of responsive design techniques — more on that later)? With over 90% of our visitors still coming in through a "desktop" computer? Probably not. But for us, there's an additional consideration of needing to demonstrate our capabilities in this area, which pushes the benefits over the cost. For many other businesses, though, that additional benefit doesn't exist.

Very few of our clients have a "money is no object" attitude when it comes to budgeting for a web project. In fact, for many of them, our costs are a bit of a stretch. But they believe in the value of what we offer and trust us to lead them to the best outcomes. It would be wrong for me to push responsive design on all of them, indiscriminate of what they know about their audience, their actual visitor data, and their actual budget. If their money could be better spent in some other way, then it should be.

via newfangled.com

Superbly practical and down-to-earth article about responsive design.

Too many creative leads (and writers) jump onto the idea of responsive design like it's the next wonderfully shiny new toy that will display their leetness, without regard for whether or not it's actually suited to what they're producing. It's refreshing to see something so logical and well-thought out about the subject.

Great user experience isn't just in the trappings - Kindle vs iPad as dead tree book replacement.

how Kindles replicate physical books is very subtle. Kindles do not rely on material aesthetics in quite the same way many skeuomorphs do. The design is underpinned by typographic and layout conventions (e.g., position of page numbers, chapter name and so on) allowing the aesthetics of the UI page to recede for the reader to become immersed in the author’s word. This is a quality any good book designer will tell you the design of a book should facilitate: uninhabited reading.

Unfortunately, the iPad book app doesn’t achieve this level of sophistication. It’s much more theatrical (as someone probably felt the need to take advantage of that fantastic color screen). The app employs elements like an overly-rendered paper texture and a faux page turn animation, which make it difficult to become quite as immersed in the prose of an author as the Kindle’s eInk design allows.

In many ways, the iPad book app was designed to look like a book, whereas the Kindle was designed to feel like a book.

via teague.com

Very good points that relate to more than just Kindle vs iPad design. Too many 'brilliant' and 'cutting-edge' designs sacrifice users' goals and purposes at the altar of looking good over being good for those using them.

I'm not sure this writer understands the purpose and function of wireframes.

Wouldn't it be nice to create prettier, more detailed versions of wireframes that can include all sorts of fancy icons, buttons and placeholders? With the Layout Lab's Web + Mobile UI PSD Bundle, you can do exactly that. Even better, you can work right in Photoshop.
via mightydeals.com

And in answer? No, no I would not like prettier, more detailed wireframes with fancy icons and whatever else prettified is in there.

Where I'm concerned, as long as information is conveyed clearly, the uglier and more unpolished-looking the better when it comes to wireframes. ._.

How not to use Helvetica Neue "Lighter"

Oh my eyes. Best (or is that worst) part is, the use of Helvetica Neue "Lighter" (not even the actual Helvetica Neue Light) was obviously intentional. Whoever designed this thought it was a good idea to make it look like this.

And they couldn't even get the implementation of their terrible idea right by using @font-face. Helvetica Neue doesn't come with the OS you know... If you really want it to look like that, so much so that you make it integral to your design and sit it on top of your font stack, then license the font.

Considering the client, one would think there's enough money for that.

P.S. If you don't have Helvetica Neue Light installed on your computer, thank your lucky stars, you'll actually be able to read the page.