“Because it sucks” is not a reason to redesign. “It sucks” leaves the scope wide open with no measure of success. It’s a sure way to scrap the good decisions you made along with the mistakes.
Instead, start the redesign with a question: “What is right about this design?” Use that perspective to identify specific problems and then target those exact problems.
Jim Jeffers
on 07 Oct 09This is a great gem! Thanks for sharing Ryan.
Chris
on 07 Oct 09Sadly a lot of agencies depend on clients who say “Our websites suck”, which is the followed by the agency saying “Yes they do suck; we’ll do a terrific redesign.” I’m trying at a local level to change this in my projects but I suspect it will continue in most agencies.
Nathan
on 07 Oct 09“Because it sucks” is a great reason to redesign a site.
The rest of the insight doesn’t seem to refute this. I agree with the general sentiment.
Jamie, Baymard Institute
on 07 Oct 09“[..] a sure way to scrap the good decisions you made along with the mistakes.”
I think “you” is the keyword here – in the scope of this discussion, you did the design. With that in mind, what I think happens way more often is that people perhaps say “this design sucks” but really mean “this design is boring, old, outdated” and that definitely is a horrible reason for doing a redesign.
If you really do conclude (through logical reasoning) that “this design sucks”, then I’ll agree with Nathan, then that is a great reason to redesign. I also agree that it will still be helpful to then ask “What is right about this design?”. As Nathan also suggests, the two are not mutually exclusive.
David S
on 07 Oct 09I like how you approach the problem from the “other side”, that is, from a positive (what does work) rather than from the angle of what’s wrong.
This brought to mind something I stumbled into recently that reminded me of you guys…a post from Optaros:
Being Interesting is Not Enough: Be Useful
When redesigning, one might also focus on “how can we be more useful?”
Deltaplan
on 07 Oct 09I have a lot of problems with some of my customers, about things like that… Many of them have a tendency to immediately discard anything that does not please them 100%. It may be an employee who is a bit slower than the others, a service provider who has been experiencing problems one day, a computer brand who has delivered a broken laptop…
The problem is, very often they come with an “obvious” replacement (usually, the biggest player in the field : Microsoft for software, Orange for phone/internet, etc…), but they don’t want to believe me when I have to warn them that changing because the former one did have problems, does not mean that the new one won’t fail either… And sometimes (many times indeed…), it fails for the exact same reason, while at the same time they have had to suffer from all the drawbacks of the “new solution” : higher prices, unavailability during the switch time, lower performance, etc…
The Well Run Site
on 07 Oct 09I disagree. “Because it sucks,” may not be a helpful description for why a design isn’t working, but it’s enough to start the analysis/redesign, which I believe are part of the same iterative process that yields effective sites. That redesign may involve small changes that are A/B tested or it may just mean scrapping the whole thing; you never know when you’re starting out, but “because it sucks” is what leads you down the path. Developers may not like to hear the phrase, because it’s too general, but often as not, that, or something like it, is how a client will describe the situation. From a client’s mouth, “because it sucks,” means “something is very wrong and I don’t know what that something is. Help.”
Dan Boland
on 07 Oct 09I think this advice is flat-out incorrect. “Because it sucks” is typically a layman’s explanation for usability and layout problems in the site (assuming we’re talking about websites), making it precisely the correct reason to redesign.
And of course a good designer would follow up on that comment by asking what works and what doesn’t, what the goal of the site is, who uses the site and for what and how frequently, etc.
RS
on 07 Oct 09This post was inspired by an internal discussion. There were no clients involved. It’s not unusual for clients to say something sucks. Client critique comes with a grain of salt. The designer makes the second step of digging in to find the “real” problem, and things move along fine as you know. That’s a normal process.
The danger creeps in when you maintain and evaluate your own products. Parts of your app will eventually seem old and crufty to you. Superficially, you’ll start to think they suck. You become tempted to scrap old screens and redo them from the ground up. That’s almost always a mistake. Since you first designed the screen, you’ve probably forgotten a lot of the problem solving and insight that informed the initial design. You may be taking for granted that the design works or even think the design works in spite of itself. You forget everything good that you did in the heat of the itch to make it all new. Then if you scratch the itch and scrap the design, all the insights and good decisions behind the seemingly crufty old design will be lost. So asking “what is good about this design?” is a preventative measure to give those good decisions a chance to shine again before the blade comes down.
Pies
on 08 Oct 09“It sucks” simply means “I don’t like it”, so I think it depends on who said it.
Pies
on 08 Oct 09But it certainly warrants an inquiry.
Anonymous Coward
on 08 Oct 09Who thought that the design suck, and whose design was it? And did it suck?
Nate Eagle
on 09 Oct 09I actually think this advice is pretty wise. “It sucks” is a philosophical conclusion, best debated by philosophers. Designers and developers need finite goals to evaluate the success or suckitude of something.
Turning the question into “What is right about this design?” is a good approach.
Personally, I think that with a mature enough crowd, you could just press for better complaints:
“The datedness of this design makes it feel old and irrelevant. We need people to be excited about our product.”
“The clunkiness of the nav and logo treatments make it look like we couldn’t afford more elegant design. We need our website to project excellence, not I-run-this-from-my-basement.”
“Nobody can find the schedule from our homepage, and that’s the biggest thing we need our website to do.”
In other words, zero in on needs—only then can we say what sucking means (not filling that need) and what not sucking would mean (filling that need).
r
on 12 Oct 09here here!
I found that projects that are considered fails are often the ones that have no defined measures of success. They are often also the projects that have poorly defined requirements, lack direction and have no real business case.
David Hobbs
on 12 Oct 09The general issue in the comment thread above is probably vagueness in defining the problem? If a client says “it sucks” or “it should just work” or some other vague comment, then the next step is figuring out what’s really needed, which may be nothing at all with the system in question. On the flip side, I’ve found that people being vague about what’s good about a system can also lead to confusion and problems (the “Just like current system” problem).
This discussion is closed.