“In this case, our approach worked, and the client’s cumbersome media management time was significantly reduced. The difference between the outcome of the two projects was simply education and support.
We should be teaching our clients to use their website, app, content management system, or social media correctly and wisely. The more adept they are at putting our products to use, the better our products perform.”
90% of my day job is education and support. 100% of any glimmer of success I’ve ever had is in properly aligning capabilities in what is being developed and expectations on how that will be used. Things are often built with all sorts of bells-and-whistles – that never get used. Why? Because no one took the time to set expectations, educate, and support the customer. Drew Thomas knows what he’s talking about here folks.
“The first time I presented design to a client I absolutely choked. I put the work in front of them and stood there like an idiot. It was humiliating. The next time was a little easier. And the time after that, well, you get the idea. I have done every one of the things on this list. I’m sharing them with you in the hopes that they’ll spare you a humiliating experience or two. It’ll take time.”
Mike Monterio (again) shares some practical wisdom for anyone who works with clients. You can design the most amazing thing, but if you can’t present it’s no good. I cringed reading this, knowing I too have made some of these mistakes.
“Making software isn’t easy. You have to make a lot of decisions and have good strong reasoning for doing so. A lot of the decisions I make are with my gut, and revolve around my personal taste. But there’s another way to design things, and that’s “safely.”
It’s not easy either, but designing safely means designing for everyone (80%+ of the population). Often, designing safely means making decisions that don’t make you happy personally. You include a feature so that someone else will like it.”
I think Louie should take it one step further. Write Opinionated Software. Don’t write mushy middle-of-the-road swiss army knife software. Write something with a voice.
I wrote this for some internal documentation around or data visualization (i.e. Dashboards) standards. I kind of like it.
Here’s something you may use every week, a gas pump. Most people probably don’t think much about how it was put together.
This is a perfect example of something made without much cohesive design. Every gas station is different, every pump manufacturer, every point-of-sale vendors, etc. Each with its own design decisions and logic. We learn to deal with these inconsistencies every time we stop for gas. In the worse case we become frustrated or make mistakes due to the lack of consistency. In the best cases all parts are easy to understand and work consistently.
In the physical world there is a long and complex history in the development of interfaces – multiple owners, physical and technical limitations, regulatory influences, etc.
However, even with those differences, we all know how to navigate this process. We’ve developed knowledge of what parts of the display we can interact with and how certain parts need to be selected first before seeing changes elsewhere.
The same is true in the digital world. People have come to rely on a lot of subtle clues to make their way through an interface: buttons have slight gradients and rounded corners, links have hover states, form fields have a soft inner shadow, and navigation bars “float” over the rest of the content.
These consistent elements are the focus of our user interface (UI) standards – the things we can make consistent should be consistent regardless of creator or audience. We have the unique opportunity, unlike the beleaguered gas station pump designers, to work together to create a shared language and experience when creating content for our co-workers.
“Using Paper, I have a sense of anxiety: what if this is what designers make when not yoked to “product thinking”? What if Matas et alia sans Jobs or Forstall are capable of impossibly perfect physics in UIs, of great elements of design, but not of holistic product thinking, of real product integrity? What if design uses its seat at the table to draw pretty things, but otherwise not pay much attention to the outcomes, the user behaviors, the things enabled?”
“In order to avoid losing its place atop organizations, design must deliver results. Designers must also accept that if they don’t, they’re not actually designing well; in technology, at least, the subjective artistry of design is mirrored by the objective finality ofuse data. A “great” design which produces bad outcomes —low engagement, little utility, few downloads, indifference on the part of the target market— should be regarded as a failure.”
Mills Baker has some great thoughts about the role of design and its impact on the success of a product. It reminds me of an old adage. “If you can’t measure it, you can’t manage it”. If design is to assist in the utility and usefulness of a product, then you should have some specific goals around what success looks like. Otherwise, you’re just spinning your wheels.
Update: Mills added some followup on Quora. He also posted it on Medium. Worth an additional read.