We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish
useful books and run
friendly conferences — crafted for pros like yourself? E.g. new
Smashing Book 5 features smart responsive design techniques and patterns.
Rian is passionate about designing and building software that people love to use. After spending several years working in Silicon Valley and Cape Town, he is currently Product Design Director at Jive Software in Portland, OR. He also blogs and tweets regularly about user experience and product management.
“Get out of the deliverables business” has become quite a mantra in the lean startup and UX movements. There’s much to love in that sentiment — after all, for every wireframe you make, you’re not shipping code to customers.
But I’m worried that, just like with the concept of a minimum viable product, we’ve taken this sound advice to an extreme that’s actually hurtful to the creation of good products. What follows is an account of my own journey in navigating these stormy design seas together with the community.
What is a product manager? What do product managers do all day? Most importantly, why do companies need to hire them? Good questions. Well, the first confusion we have to clear up is what we mean by "product."
In the context of software development, a product is the website, application or online service that users interact with. Depending on the size of the company and its products, a product manager could be responsible for an entire system (such as a mobile app) or part of a system (such as the checkout flow on an e-commerce website across all devices).
How do you convince clients to trust you with their valuable and much-loved product? In my experience, the best way to sell work to clients is to apply user-centered design not only to the work we produce, but also to the clients who commission that work.
We have to understand who our clients are, what is important to them and what their goals are. And then we have to deliver work that not only meets the needs of end users, but also satisfies the personalities within the company itself.
I have an idea for a new product — can I tell you about it? It will take months to develop, and even though this kind of thing is usually given away for free, I’m going to charge for it. Oh, and the market for it probably won’t be very big… Wait, come back! Where are you going?!
It does sound like a crazy idea, but it’s exactly what a small group of designers and writers have been doing for the past year or so. On a Web littered with SEO-ified headlines (“17 Jaw-Dropping Responsive Design Templates and Funny Cat Pictures”), easy-to-share design gallery slideshows and quick tutorials that help you recreate the latest texture fetish in Photoshop, these people are taking a step back from what we have now come to refer to as the “fast Web.”
My relationship with the Internet oscillates between waves of euphoria and waves of angst. Some things make me extraordinarily happy: like a client who loves usability testing so much when they first experience it that they can’t sleep for days; or connecting with someone whose writing I’ve admired for many years.
But other things make me want to close my computer forever and go live on a farm somewhere: like people who take entire articles and present them as their own work, with tiny source links at the bottom of the page; or endless arguments and name-calling that ignore even the most basic human dignity.
We’d like to believe that we use established design patterns for common elements on the Web. We know what buttons should look like, how they should behave and how to design the Web forms that rely on those buttons. And yet, broken forms, buttons that look nothing like buttons, confusing navigation elements and more are rampant on the Web. It’s a boulevard of broken patterns out there.
This got me thinking about the history and purpose of design patterns and when they should and should not be used. Most interestingly, I started wondering when breaking a pattern in favor of something different or better might actually be OK. We all recognize and are quick to call out when patterns are misused. But are there circumstances in which breaking the rules is OK? To answer this question properly, let’s go back to the beginning.
I spend a lot of time buying and testing iPad apps for kids. To be more specific, I lovingly do this for a certain two-year-old girl who is currently on a very successful #OccupyiPad mission in my house. Through extensive observational research, I’ve discovered what works and doesn’t work for my daughter, so I’m going to shamelessly generalize my findings to all children and propose four essential guidelines for developers who work on iPad apps for children.
Most apps for children show a bunch of different things on the screen that you can touch to make stuff happen. Cows moo, windows open and close, honey pots need to be collected, etc. But most of these apps give no indication of which elements are interactive and which are not. This usually results in a frantic and frustrating game of whack-a-mole to find the elements that actually do something.
Have you ever looked at a bizarre building design and wondered, “What were the architects thinking?” Or have you simply felt frustrated by a building that made you uncomfortable, or felt anger when a beautiful old building was razed and replaced with a contemporary eyesore?
You might be forgiven for thinking “these architects must be blind!” New research shows that in a real sense, you might actually be right.
There are many ways to skin a redesign (I think that’s how the saying goes). On a philosophical level, I agree with those who advocate for realigning, not redesigning, but these are mere words when you’re staring a design problem in the face with no idea where to start. This article came out of my own questions about how to make the realignment philosophy practical and apply it to my day-to-day work — especially when what’s needed is more than a few tweaks to the website here and there.
I propose an approach to redesign through realignment, by using a framework adapted from Edward Tufte’s principles on the visual display of quantitative information. But first, a little context.
In part one of this series, we looked at the consequences of designing and developing software in isolated environments. Some people work in lonely silos where no process exists, while others work in functional silos where too much (or the wrong) process makes innovation and progress difficult.
So, how do we break down the artificial walls that keep us from creating great things together? How can organizations foster environments that encourage natural, unforced collaboration? There are no quick fixes, but these are far from insurmountable problems.