This discussion of minimalist posters got me thinking of some of the design problems I have been encountering lately. And that got me to thinking that I have been seeing a variation of this for years and years.
Unlike much of the graphic arts scene, it seems that interactive design hasn't gotten over it's trend of simplicity and whitespace for their own sake. If anything it seems to get worse year after year.
While I won't quite blame Apple – and everyone else who follows that design ethos of spartan minimalism in everything – this is the design I am talking about.
But the problem isn't really that we're stuck in a design rut. We are, but it's much more that not everyone evaluates everything the same way, with the same depth. People use a cool new product (on their iPad), then come to work the next day and say we should make a product as clean and easy to use as this.
But "clean" and "easy to use" are different things. In the same way that "look and feel" are two different phrases (hence the "and").
"Clean" rapidly becomes misinterpreted as "low-featured."
"Easy to use" becomes misinterpreted as "easy for every single person in the world to use."
"Simple" turns into "simplistic," and we cut features not to get to core principles, but because they are visible.
We cut features not with a knife, but with an axe.
And rapidly, any feature is worthy of being assailed not on it's merits, but on it's immediate visual appeal in a wireframe, or comp.
But it's a false argument. Anything, – anything – can be assailed as cluttered, complex, or any number of adjectives that are, really, meaningless.
There is no way to argue against "you don't want to confuse the user..." on it's merits, because there is no internal logic to this argument; it has no merits, really.
I routinely want to challenge such arguments and bring us back to principles, or to the scientific underpinnings of the practice. "Hard for which users?" or "But this feature is required to meet objective 2…" or "But the research proved that 100% of the participants prefer…"
So maybe we can win the argument by counter-attacking their premise, and getting to the core of the issue like this.
At least on the face of it.
Because really, we're missing a key point by calling it a design issue. It's a communications issue, or maybe (as Alexandra Lange responded in the comments on that Design Obsever article), an issue of design criticism. I admit that I would not have made any of these connections without her article.
As practitioners of IxD, UI and UX, we try to make decisions based on provable knowledge. You could even characterize it as a scientific approach to design.
But it's not always true. Opinions still abound in discussions amongst ourselves. About interpreting what actually happened in a test, or what situation we are really looking at, so what heuristic should be applied.
If you were to watch a design (or art) critique session, you might think it's just a conversation, but really this is a fairly formal construct, with rules that make it work to everyone's advantage.
You cannot complain about a work without merit; "I don't like it" doesn't fly. You better have a good, reasoned argument as to what you don't like, in what manner you don't like it, and maybe even suggest a solution. It better address the intended audience, or the purpose of the object. Assuming use outside of this may be irrelevant.
As the creator, you better accept all criticism, and I don't mean passively; you have to engage in the conversation, to make sure everyone understands each other, and so group discussions can help reach consensus on the best course of action. Note that I didn't say "solution." One individual still ends up cutting the wood, or painting the line, or placing the pixel. Iterative critique gets it closer to the intended goals.
Mostly, you cannot perform design criticism alone, or as the only proper practitioner of it; everyone has to participate and follow the rules.
Interactive design doesn't have any of this. Sure, your studio might work fine. And I have absolutely been on teams – or led teams – that worked exactly like this and had terrific group design critiques (and terrific products came out the other end). But as a whole discipline we do not have a method of critique.
We argue, cajole, express opinion, refer to previous solutions, and our favorite products. We make deals, and end up splitting the difference so we can stop arguing and get to the next point.
We decry ornament (especially when we bow to the altar of Clean Design) and insist we evaluate based on interactivity and process.
All while we draw comps and complain about crowding objects, and demand white space be added or everything align to the grid.
We carry out common practice, and build what is easy, instead of finding and defining what is truly, demonstrably best practice.
We do not share, or tell anyone else about our design solutions. Maybe not even the guy in the next pod, but almost never to the design community as a whole.
We design in isolation, take criticism as insults to our work, and believe there is design that cannot be improved upon.
We perceive openness to opinion, fuzzy concepts or acceptance of change as weakness. We are simply confused (and maybe assume it's a trick or insult) when a designer offers to change to an alternative design when a good point is raised by others.
And we cannot fathom why our clients do not respect interactive design and user experience as evidence-based, consistently-applied, professional fields, and express sorrow every time they insist we change something based on whim.
We need an ethos of design criticism.
Not a process. The existing ones for fine art and design work fine.
And we must not stop disagreeing with each other. We must not stifle creativity, or reduce iteration, or work more in isolation from fear or as a res
Of course you know that arguing with the client never really works. I said that up above because that's what I want to do, but another approach is needed.
So, if you agree, what next? Well, it's simple. Do this. Tomorrow. Okay, it's the end of the week. So, Monday. The next time you bring the team together, lay out the ground rules and tell everyone this is how we're going to talk to each other.
In several ways – but especially in becoming a seasoned practitioner of art and design criticism – going to art school was maybe the best education I could have gotten. I've been thinking for a long time we need to teach not just what you should know, but how to do it and how to do it with a team. Not every field of study or school does this. You can make sure to teach your junior designers the skills they need, and not just assume they will pick it up on the way.
And you can try to get the right feedback from everyone.
When you walk to someone's desk, and they give feedback, ask them to justify it, very precisely. Nicely, but get to the heart of it.
Anyone can answer these questions if pushed to it. Not naturally, but they can. Even your clients. If you are told "why not more like how Amazon does it?" then pull up that part of Amazon, and ask in what manner this solves the need. Ask how this meets the goals of the product, ask questions you know that there are answers to, or which they will enjoy answering.
As much as it's been talked about, there is no certifying organization for IxD.
As much as some people get to write books (now me!) and get followed by thousands of people every day, there is no one guru who can change the whole field. We all do it, every day, as we work with each other and improve interactive products.
If you like this idea, do it. If you have a better one, do that. But if anything ever bothers you about how our field works, talk about it, find a solution, and put it into practice. This is how we improve ourselves, and our little part of the world.
Showing posts with label collaborate. Show all posts
Showing posts with label collaborate. Show all posts
Wednesday, September 14, 2011
Monday, January 11, 2010
How to Criticize Design
I regularly encounter people, or posts, that refer to all criticism as bad. That it stifles creativity, especially for us sensitive artsy designer types.
I could hardly disagree more. Criticism is a key part of discovering new ideas and working collaboratively. I am not brilliant enough to get by without help from others.
This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review. This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others' work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.
Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that's usually fine. For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer's intent are generally a bad thing. Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others... actually, Wikipedia has a great summary of this:
Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn't always happen though (scheduling, remote work, etc.) so the big review is still a part of my life. I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there's a good creative team at the client) I'll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.
More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it's easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door. As a reviewer, and especially as a client reviewing design you have paid for, here's my ten tips for participating in a design review.
This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review. This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others' work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.
Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that's usually fine. For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer's intent are generally a bad thing. Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others... actually, Wikipedia has a great summary of this:
It is difficult for authors and researchers, whether individually or in a team, to spot every mistake or flaw in a complicated piece of work. This is not necessarily a reflection on those concerned, but because with a new and perhaps eclectic subject, an opportunity for improvement may be more obvious to someone with special expertise or who simply looks at it with a fresh eye. Therefore, showing work to others increases the probability that weaknesses will be identified and improved.Even the simplest system I have worked on in the past decade is so complex I can't hold the design in my head (and I am pretty good at this). The genius designer only goes so far, which is why my design documentation was created, and why I make myself stick to it. Another way to think about this is in this posting about reviewing for journals:
In the early years, critique is about identifying holes and mistakes that make ideas less plausible. In the later years, critique is about identifying the germs of ideas worth development despite the current holes and mistakes.In this sense, the value of critique is not unlike that of the concept reviews and brainstorming your may have done with the designers when they first came onto the project. Your critique (assuming the schedule allows for it) is not just to tweak the design, but to discover whether there is something totally brilliant or totally different hiding somewhere in there.
Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn't always happen though (scheduling, remote work, etc.) so the big review is still a part of my life. I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there's a good creative team at the client) I'll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.
More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it's easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door. As a reviewer, and especially as a client reviewing design you have paid for, here's my ten tips for participating in a design review.
- Look at the product. Review it as the designers wish you to. Feel free to take notes, but let the review be completed (whether a self-directed website walk through, or a presentation) before offering any feedback. Whether it's a complex product, or your needs mean the presentation is out of first-time-user order, or the designer is just not that good as public speaking, you often will need to see the whole thing before you understand it fully.
- Encourage everyone else to do the same. That is, take notes and wait till the review is over. Short circuiting this in meetings especially means you might not even get to the good parts, and spend the whole time arguing about the terminology of the signon process.
- Follow up with details. Email is a great way to send more thoughts. Whether something didn't occur to you at the time, or you are just a junior flunky and didn't get a chance to speak up in the meeting, written commentary is useful. But do it quickly, before other changes are made or you forget the rest of what you saw.
- Express your personal opinions on how you might use the product. User research is just lots of personal opinion and observation, codified, so if nothing else your opinion can be slotted into existing knowledge, and explained. The "worst case" is that it's a brainstorming sort of point, and something else good can still come of it. Don't, however, believe that your experience is necessarily of key relevance.
- Relay anecdotes about use or understanding. Don't spout pithy sayings "my mom couldn't handle this" but do cite specific cases that seem relevant. Whether it's the first impression of someone looking over your shoulder, or just what your heard some people say about the competitors product, that you worry this doesn't do, it's okay to bring it up if it hasn't been heard before.
- Quote solid information. Even if it's "just" a marketing study or three year old use statistics. Ideally, the designers already know this, but if not it's definitely time to bring it up. Even if they do, explaining that you have concerns about the design because of specific background information is a useful place to start a serious discussion.
- Express personal opinions on style, aesthetic, etc. These might be trumped by brand standards, or consistency, or some other design needs. But bring it up. You might have found a hiccup in the standard implementation, or something else that needs to be fixed.
- Everyone's opinion is equally valid. Just opinion. If they have data to back it up, that's different and usually trumps opinion. Even if you are the VP of everyone in the room, and authorize payment to the design agency, your opinion is still opinion. Your employees (and the vendor) were presumably hired because they are good at their jobs, so trust them to say useful things.
- Allow the designer to counter your input. Don't feel sad about it, because it's not personal. If they have solid research, or experience, then think about trusting them on it. My guidance, whether reviewing other designers' work or talking to clients, is "if you have a good-sounding story, I believe you." Assuming you trust the guys you hired to do this work, you don't have to understand what they say, but do make sure they sound like they understand what they are saying. Treat design like anything else you pay good money for, and trust their well-founded argument.
- Review the changes later. Designers forget stuff, or don't understand, or might make a new solution once they get back to the office. This is another reason you should write everything down. Don't nag, but if you thought you understood that something different was going to happen, ask why. And feel free to ask for clarification; "we think" should be able to be followed up by "because of user research that indicates [something specific, with numbers]."
Labels:
business,
collaborate,
design,
learned skills,
speaking,
tips
Subscribe to:
Posts (Atom)