Why Johnny can’t build a decent user interface
jeffreyellis.org
jeffreyellis.org
I recently wrote someone a recommendation where I argued that programming languages and patterns are readily teachable, but holding a complex model in the mind and communicating it effectively to peers, laymen, or computers (the computer is the ultimate simpleton) is less easily taught.
I agree with your linked comment about teaching. One university teacher told me that to lead someone to your point of view, you must first put your arm around them making you start the discussion from where you can see theirs.
I've been "programming" in one sense or another since I was about eight years old. Anything that you have been doing that long since that early is going to seem "inborn" if you don't think about it hard enough.
Certainly, some people are better at certain things than others (just watch me throw a ball), but that can be overcome with hard work (IMHO).
Most engineers who set out to "make the UI" aren't willing to make those sacrifices, so you get a crappy UI. That's not meant to insult engineers, because they have plenty of other things to worry about. But unless you take it truly, painfully seriously, all you get is shit.
So in real life, capable professionals usually have some innate talents. But it doesn't have to be specifically ux design talent. maybe a talent in fast learning , and grasping complex stuff could be used. maybe a deep natural empathy you have with users.
- Deeply understands the technology involved and how people want to use that technology
- Looks at UI the way users do and is disgusted by pain points (ala Steve Jobs)
- Empathizes with users who use technology differently than they do (or anyone else on the team), and is able to build out UI specifically for their use cases
- Wrangles the development team to do everything possible to make life easier for the user; set-up that auto-detects your rig, Mint's on-boarding process where all you have to do is enter your username and password from your bank website log-in, etc.
- Concepts and implements things like emotional hooks, look-and-feel, embedded tutorial, etc.
These things are "seen" and not "done" like playing the piano or other activities which require 10k hours to master. Some people have excellent product experience vision and give themselves permission to use it in a business context. Other designers will push pixels their whole careers.
Some people think deeply about why they do things, others don't. I think that's the critical skill in UX design and cannot be trained.
In time, the more designs I made, the more I started to develop an intuition for things that worked or didn't work. Not to mention that before I learned how to design, I had to learn how to listen to my users - and before I could do that, I needed to learn to check my ego at the door and realize that even as the "designer", it didn't mean I knew a darn thing about what my design should look like until I talked to them (and sometimes, not designing what I originally "wanted" to design as a result). Yes, there are definitely skills involved in "doing" things that are hard to train, and there's a sense of "natural" talent - but with enough effort, even a computer science major like myself can pick up those skills.
And conversely, the hours you spend doing design are hours that are necessarily taken away from other things you want to be an expert on. Like NoSQL databases, or sleep. :)
Some background - I'm a software engineer, with my true love being application design, though I have often worked in other fields. My brother is an architect, so he has had quite a bit of formal schooling in design technique, and well, he just enjoys doing it. Anyway, when we get together, we have a game we like to play where we pick an average every day device, and we try to design a better user interface for it.
There seems to be a very constant sequence of actions that we do when playing the game. The most important of all is to start playing the game - which is to say if you aren't trying to improve an interface, you never will. But once we start trying to improve an objects interface, we generally start by identifying flaws in the current design, the pain points. Once those have been found, we start tossing around ideas that might fix the flaw. It's at his stage that something interesting starts to happen - you get a deeper understanding of the problem the object was trying to solve, and that understanding frees you up to try something really different - the old smartphone to iPhone type of jump.
To give an example, the last time that we played the game, we were working on traffic lights. Some of the flaws that we found included:
Light bulbs that blow
Lights get lost in the background of dense cities such as Paris or London
The posts take up valuable street space, making them a hazard for pedestrians and dangerous if a vehicle loses control.
Inflexibility to changing conditions - for example, when I'm the only driver on the street for the last 10mins, why can I get stopped at lights for a minute waiting for it to go green?
Once the flaws are identified you can start tossing around solutions. In the case of the traffic lights, we started to understand that the object itself was the problem. Traffic lights are a solution that was designed before the advent of ubiquitous computers and wireless communications. These days you could design a system where your car receives a signal from any intersection saying whether it has tonstop or not. The traffic light itself can be moved inside the car, or even tied to the control system if you are about to run a red light. That would be a good first step, no more poles, no more distraction from blinking neon signwork. But ther would still be the problem of maintenance, the radios could blow. And it still doesn't stop you from getting stopped at an empty intersection.
Our next iteration required a deeper understanding of what traffic lights are actually trying to do, rather than just understand what they are doing. They are trying to control traffic flow. So, the final solution to traffic lights is to find a better traffic flow solution. In our game we eventually decided that ai cars, capable of driving themselves and connecting to a regional traffic control server, would be able to negotiate their passage at each intersection. No more traffic lights anywhere in the system, because at the end of the day they are a hack that was created as a stopgap solution at a time when we didn't have the technology to do any better, and which now continues on due to inertia.
Anyway, if you keep playing the game, you eventually get to the point where you really start to understand design as being an attempt to get to the heart of the problem you are trying to solve. This process helps you find the original solution to the problem that makes your object a plaesure to use rather than being something that you have to fight against
The last 6 paragraphs are fairly obvious points where you do not go into detail or give examples. How is the reader supposed to know what you mean in a way that is useful? Some links to examples or how to implement would be useful advice.
Also, I'm curious, why the snarkiness? Do you consider being critical of others to be part of your online persona? Is it for entertainment value? Is it an effort to improve something? I don't mean to pick on you - I'm actually curious.
Words like 'mad skillz' imply condescension towards some hypothetical group of developers. Words like 'self-serving', 'lack of', 'incompetence', etc are just negative - again targeting a straw-man group of developers.
Within your article there seems to be a paradigm of a) stuff that 'sucks', and b) the 'right' way (your way).
So, it leaves me thinking that you are targeting a negative generalization towards a group of developers. Effectively, you created an ad hominem argument against a straw-man. This comes off as negative, but more so it tells me as a reader that you spent energy evaluating the scenario from the standpoint of 'this is wrong', without fully understanding the point of view of your straw-man or pointing to examples of good design.
Instead of conveying 'these guys over here suck, they should do it my way' you could have conveyed 'these guys over here can suck, but when I have observed them doing x, y, z they definitely suck less' - same message without the ad hominem. Or, even better 'these guys over here are good at design vs average engineers because they do x, y, z' - same message with an emphasis on positive examples, not negative examples. That would convey that you have taken the energy to evaluate both the negative and the positive about the straw-man developer group you appear to be attacking.
As a general aside, I have been trying to understand why many smart / skilled people bias towards viewing others in a negative light - ie, does it have a benefit? I am generally interested to understand where this negatively comes from when skilled people evaluate their peers.
Yes, but as the OP points out it's advice for Johnny, as opposed to a more general indictment of society.
1. Giving users what they ask for; and
2. Designing to sell.
Isn't one of the things that generally makes Apple's products arguably great is that the hardware is designed to be true to its purpose, and the marketing campaign is an entirely separate and often equally brilliant thing, also true to its purpose...
There was definitely zero interest in making my experience a good one. Somebody marketing committee had gotten ahold of the product and this was the result.
1st thing I did: wipe it and reload the OS. With OS media I had to buy separately.
In my opinion, that makes it a pretty weak argument that detracts from the rest of his article. Besides that, it could have the effect of discouraging people from trying, as they’ll just think “Oh well I can never do that because I don’t have the genes, or whatever.”
My opinion is that programmers in particular have a hard time with design because they’re not presented with a systematic way of thinking about it. That’s what I’ve started to try to do with my site http://www.visualmess.com . It tries to instill the “user-centric” mentality and provide a framework for thinking about design based on the brain’s visual information processing capabilities.
If software is sold based on a checklist of features then it is more important to build ten ugly features than one beautiful one. If software is sold based on beautiful demos then it pays to make the demo awesome but skimp on the corner cases. If software is sold based on gorgeous screenshots and icons then the median icon or screenshot will be gorgeous, even if the app itself is missing or broken. (Even the broken iOS apps have beautiful, beautiful icons.)
If your company has so many layers of management that the feedback from end users never makes it back to your desk, you'll generate designs that please your management.
If you're at a bootstrapped startup, searching for product-market fit, it pays to design incrementally. Even if incremental design is the wrong approach for the problem, it still pays to design incrementally, because a better-designed app with no market is a disaster. That means that there are many theoretically possible designs that are difficult or impossible to achieve in practice.
The trick to improving the design of software is to figure out how to make it pay. A major enemy is the rate at which the landscape changes. Computing still changes so quickly that there's a premium on disposablility. The jury-rigged contraption built of metaphorical duct tape may be barely usable, but it's cheap and quick to build, and in a year nobody will care: They'll have traded it in for the next model, or the platform will be obsolete and everyone will have to move, or you will switch jobs (perhaps by selling the product to Cisco) and you won't care anymore.
It took me a long time to appreciate the difference a great interface makes for an application. For me the problem comes from the original team that start building out product. They are working on sweat equity, don't have a $1 to spare and are rushing to market. If they don't have a designer among them, the design and usability gets moved to 'When get some traction, we'll redo this' and it never gets re-done and more items are piled on top of the quickly made UI. By the time the product ships the UI is almost unusable.
I'd argue that the latter is true.
Firstly, in text mode, screen estate is limited. One has to be careful in what one chooses to display on the main menus.
Secondly, we already program in text mode. Creating text mode menus poses less cognitive dissonance for the programmer than dragging and dropping radio buttons and menu bars.
The bad user interfaces that I've seen usually present all available options within the main screen, and it ends up being a crapfest of controls with no obvious guidance to the poor user as to what is a sensible next step.
Text menus also present a very structured way for users to explore a program. If you made a mistake, you have a better chance of retracing your steps. In contrast, WIMP systems may present multiple entry points for a single functionality, with little information on how to undo one's changes. Toolbars are the worst in this respect. The button that one clicks to "perform" the action is not the same button one might use to "undo" the action.
I might be biased, but I always held this as axiomatic truth.
Oh how very, very ironic.
The Yale school of Art.
Looks more like the toddlers school of scribbling.
Usually it's just: some graphic design expertise, and WoW addict like dedication to smoothing out the details.