This morning, I happened upon "Wired's Essential Apps for 2011" and quickly found myself frowning. I wasn't frowning because of the Wired editors' decisions about which apps are the best, it was because I was frustrated with a glaring design problem in their article and I suspect I know the reason it looks so bad:
Developers Built it That Way
It's not an isolated problem, really. A developer is given a functional spec that calls for a grid display of 'apps' which will have a company name and the app name. Seems reasonable, and with most modern CMSes, probably not too hard to build, either. It looks great with dummy lorem ipsum content when shown at the design review meeting, no one ever stops to wonder if their content will actually fit the requirements, though. And then when it comes time to put the real content in both company name and application name are required fields, so when you come to a company that is self-publishing an eponymous app, like Netflix, then your editors are stuck. They are forced to do something they know is wrong and they put the same name into both fields.
It's easy to pick on Wired, but this is something I see (and, I'll admit, have done) on any number of websites. Maybe it's the nature of building and using content management systems. We do a lot of work with Drupal around here and I think it's safe to say we run into this problem somewhat regularly. We build interfaces and want them to be easy–excruciatingly easy– for editors to use to create and manage content. So we separate content out into separate inputs in the content creation screens, we make different 'content types,' we create arbitrary divisions between what is content and what is 'auxiliary content.'
Recently, there was a bit of a scandal in the WHATWG around one spec editor's personal plan to deprecate the <time> element and replace it with something he saw as more appropriate. Jeremy Keith wrote a blog post about the event and in it talks about one of the key decision-making guidelines for the HTML spec: the Priority of Constituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
It seems to me that this would be a great guiding principle for CMS developers, too. Of course, with CMS development you might have many types of users: visitors, commenters, contributors, editors, managers, administrators, etc.; so how do you decide who should get precedence? I think the Priority of Constituencies still speaks to this scenario: privilege the visitors of your website over your content creators and staff over your developers.
What do you think? Do you see developer-enforced design flaws in the sites you visit? In the work you do? How can we bring the Priority of Constituencies into our work as website and CMS developers?
Ah, this happens all too often. It seems to me that it really comes down to two problems many companies see over and over.
Developers often feel pressured to keep their heads down and work through any problems they find. We should always be empowered to speak up, even when fixing that problem causes delays. Speaking up early is one of the keys to fixing bad user experiences before they happen.
And how often do we get real content early enough in the process? Lorem Ipsum and filler text is routinely the only thing to go on making it impossible to evaluate whether or not the architecture is appropriate. The sooner we can use real content the sooner real problems are found.
I feel like you really jumped to a conclusion here in saying "Developers built it that way" is the fundamental problem (unless you're saying the developers were just doing their job and the designers did a poor design because they were using Lorem Ipsum?).
I would say "The team built it this way" is the problem and "The business-folks won't let them iterate to improve it" is potentially a more root-level problem.
I can somewhat side with the last comment. True the developer did build it that way, but the question becomes - Why?
In previous lives I have been both designer and developer. I have seen both sides, short sighted designers, and developers with tied hands or no UX sense.
I can't count the times in both positions that I got something that was obviously wrong, but was unable to correct it because of a spec created by someone in a suit. Then the suit that gave it to me was to scared to go up the chain of suits and look like fool. So I was forced to create junk.
In the past I would be shocked to see such from Wired, however they are no longer the independent voice of old, which is why I rarely give them much thought these days.
I disagree with this analysis. The format is "Business Name" "Product Name." A lot of apps listed are made by company that uses their business name for the product name.
You're right, I am somewhat jumping the gun by laying the blame on the developers. I agree with you @greggles that agile, iterative design and development (along with rapid deployment) could have helped find and fix this problem faster. And I agree with you @David that working with real content and not dummy text is an important early step in finding out where our assumptions end and the real world begins.
Most likely the decision to force this interface was not just the developers decision.
I blame the developers because I am a developer. This article could have easily blamed the designers, the managers, the quality assurance team, or the "suits," but I felt that really, it doesn't matter who made the ultimate decision, it matters that no one challenged it. As developers, we're probably the last people to "work" the designs or functional specification before it gets hands-on by actual users (be they content editors or viewers).
I feel that as developers we should be empowered enough to push back when we know we're willfully degrading the end-user experience.
Sure, we've all had the hard-line client who absolutely insists that their way is correct "no ifs, and, or buts about it," but we know better. In the same way that we (or at least, I) would push back if a design came through in "Marker Felt" and "Comic Sans," or if a business decision came down to make the browser's "Back" button always return you to the homepage no matter what your last viewed page was, we (I) would push back as soon as it became apparent that always displaying a company and application name was going to create a confusing looking interface for eponymous applications.
Developers, Designers, Product Owners, Managers -- we all have to look out for each other and be empowered to speak up when we see something that doesn't make sense.
I think if we apply the Priority of Constituencies to our work we can say that we aren't developing websites for ourselves, or in some ways, even for the clients paying the bills; our job is to keep the end-user in mind.
One more of many examples how the Drupal community has failed the user:
Verify changing user email addresses.
tl;dr: After 5+ years, a basic feature request to improve UX and data integrity is still ignored with the excuse "this should live in contrib"
... and here's that link.
http://drupal.org/node/85494
PS. Please note the irony of your blog post post, given that your own blog's "input format" instructions below the comment form are completely inaccurate.
On the Blog Input format: Yes, believe us - we get that and we're planning that along with many other things on the website. Part of what Brian is discussing is something of the philosophy we'll be approaching it with.
Post new comment