Yahoo! Design Patterns and Yahoo! News

My mentor, Diane Deseta at UXMentors assigned me an exercise to examine how Yahoo! implements their  Yahoo's design pattern library throughout their site.  This is one of several posts drawn from that assignment.

The exercise brought to light how complicated it is to follow conventions when there are competing motivations behind a page.  In several instances, the patterns were ignored.  Whether these divergences were created by or inherited by the recently fired SVP for User Experience Design Tim  Parsey is impossible to know, the end result left my brow furrowed.

---------

Example studied: http://news.yahoo.com/vote-gay-youth-scouts-face-more-turmoil-203143778.html 

Navigation Tabs - APPLIED WHERE CONVENIENT - The use of navigation tabs is to provide a clear way for the user to see where they are (in this case - in the Yahoo! News section) and easily determine how to get to other parts of the site. 

The place where this convention is ignored is the number of tabs.  The design pattern explicitly says no more than 10 tabs should be used though 13 appear here.  

Why violate the pattern? I’m guessing there are 13 individuals who have titles that correspond to curating the sections delineated by those tabs.  

The solution to this would seem pretty clear cut - merge a couple of the tabs.  Science/Health/Technology seem good candidates, and "local" and "popular" don't even seem to be the same kind of label, thereby further diluting the power of the convention.  Even the example given in the design pattern shows a different implementation from the one being used on the live site.

Here’s the example given with the design patterns:

Here’s the live page:

I'm guessing the people responsible for curating the site have louder voices than those who compile the design patterns.

Page Grids - FOLLOWED - The layout of the page uses the large column on the left and a thinner column on the right (the first pattern shown among the four preferred layouts):

The pattern encourages the use of these grids because:

·       Templates reduce designers' preparation time and let them focus more on the site's content and features.

·       Consistency across pages and page elements contributes to a cohesive brand and user experience.

·       A common source code offers a number benefits:

o   Reduces the number of subtle or major variations in the page layout.

o   Expedites development and global page updates.

The code for the page shows that a CSS and HTML template was indeed used to lay out the page...these templates are likely populated by the CMS used for news items (which, themselves, are also likely auto-populated by content providers (in this case AP)

Yahoo! Design Patterns and Shopping; Search results pages

My mentor, Diane Deseta at UXMentors assigned me an exercise to examine how Yahoo! implements their  Yahoo's design pattern library throughout their site.  This is one of several posts drawn from that assignment.

The exercise brought to light how complicated it is to follow conventions when there are competing motivations behind a page.  In several instances, the patterns were ignored.  Whether these divergences were created by or inherited by the recently fired SVP for User Experience Design Tim  Parsey is impossible to know, the end result left my brow furrowed.

---------

Yahoo! Shopping page examined: http://tinyurl.com/kbahrvc

Rating an Object - UNCLEAR - The mechanism for rating an object follows the conventions of the design pattern, but one "consideration" appears unconsidered (or, if addressed, was decided against ease of use).  

The pattern states "Consideration should be made about the call to action for a rating if a user is not logged in." and while I can't know IF consideration was actually made, the result was that if someone goes to rate the item, and they are not logged in, they are yanked from their current page and forced to log in.

The stated purpose of the star rating device is allow a user to quickly leave their opinion...but forced log-in defeats that purpose.  Perhaps greying out the stars (or a tool-tip saying ratings can only be left when logged in) could help achieve both goals, but that doesn't happen.  

This may have been accidentally overlooked, or perhaps done to use this function to encourage people to log in so buying behavior can be tracked...but it discourages user input in favor of potentially gathering better data.  Since that purchasing data can be valuable, I expect the decision was made to force log-in...but surprising the user with that decision seems lazy.

Top navigation - FOLLOWED - The design pattern seems to state that the top nav could be accompanied with a secondary level of navigation, but since each product would likely bring the user many levels deep, they chose to use breadcrumbs for that purpose.

Breadcrumbs - FOLLOWED - Unlike on the travel page, the use of breadcrumbs on the shopping page precisely follows the design pattern.

---------

Yahoo! Search results page examined:  http://tinyurl.com/latqyav 

Search Pagination - FOLLOWED - While the conventions for Search Pagination are followed, extraneous boxes are drawn around each number in a well-intentioned attempt at a "re-design."  This additional non-data-ink would make Edward Tufte sad.

Module tabs - IGNORED - The design patterns include a way to handle multiple kinds of information on the same page...using module tabs.  The search results, though also displaying different kinds of information (in this case results), instead use a quasi-top-nav format that's neither a top nav nor module tabs.

I expect this was ignored also due to a desire to "re-design" and "freshen up" the results.  

The Elements of User Experience

Not everyone is as lucky as I was.

While some people stumble onto the principles of UX by asking deeper questions about their software designs (Is the navigation intuitive? Does it make sense to users to put this button here?) they are forced to find their way through the field alone.

I got lucky in simultaneously finding a field and a mentor.  Diane Deseta with UX mentors thoughtfully brought me along in the UX world, starting me off with the basics.  After studying the Morville and Rosenfeld 'Polar Bear book' on information architecture, she insisted I read The Elements of User Experience by Jesse James Garrett.

While much of what I've learned has helped me to hone skills related to specific aspects of software development, this book lays the foundation on which all of those skills are useful...which is why I'm so lucky that Diane insisted on my reading it so early in my education.

Garrett says products are essentially a conceptual layered column (shown at the right) built on the foundation of a strategy with each successive layer building on the one below it.  He says that without a strong, clear concept of the lower layer, each successive step is more fragile.

For example, every product must have a clear strategy.  Not only a clear business strategy, but a clear vision of what the purpose of the product is.  Some large companies make the mistake of keeping this information closely held at the highest levels of the company, but that leads to lower level decision makers blind to the intended strategic direction.  Without a clear vision of what is to be built and why, all the following decisions made for the product will be determined by varying visions of the goal.

Below that is the scope of the product.  The concern of feature creep and scope creep comes in here.  Without a clear sense of what the product should do (and, more importantly, what is outside the scope of the product) its design can never be finished.

After this is the structure layer.  In the case of content sites this means information architecture.  Clear organization for all the various information that populates the product BEFORE the other steps in product development are taken will lead to a seamless experience for the user.

Only after discussing these crucial considerations does Garrett address the skeleton and surface of the site: the buttons, color, icons and graphics of the page.

In first learning how websites work, I made the mistake of designing the front-end stuff first.  My experience had only been with the buttons and graphics of a site.  Well-designed sites make their inner working invisible to the user, and this book showed me the unseen elegance of a well-designed site.

Sites that excel are brilliant not just because of a beautiful interface -- they excel because every layer of the site represented in Garrett's diagram was designed congruently with the preceding layer.

Ironically, as the book teaches that well-designed sites have a thoughtful and robust foundation, the book itself provided just such a foundation for my own education.

Learning from other people's mistakes

"There, but for the grace of God, go I" - John Bradford

When faced with coming up with new site ideas or designs, it can help to look at examples of brilliant design.  When examining the specifics of a Google map interface, or how Apple designs its sales pages, you know that teams of the brightest minds have worked to compile some of the best content available today.

There are times when bending to the extreme can be just as helpful, and this is where the fine people at webpagesthatsuck.com leap to the rescue!

I came across this site while taking a lynda.com course from Sue Jenkins, and it continues to provide both laughs and lessons.

Vincent Flanders compiles a list of laughably bad websites and while mockery on the internet is nothing new, the author actually includes a clear explanation of the errors being made and why to avoid them.

An example is this review of the gif-laden interpretation of the afterlife.  Perhaps this was meant to be an artistic piece and not entirely an educational web page, but the lessons to be learned here are substantial.  Apart from the obvious (avoid flashy graphics that could cause seizures) are subtler lessons about not taking away the users ability to scroll under any circumstance and to include some navigation so they can derive context from your content.

Of course, part of the fun is in gawking at the painful mistakes of others, though the opportunity to do so while actually learning something about design is worthwhile.

Living with complexity

Don Norman's book The Design of Everyday Things has become a touchstone for those of us with a penchant for design.  It has introduced hundreds of thousands to his elegant view of the world and uncanny ability to pinpoint the essence of why some things just FEEL well designed.

His most recent book, Living with Complexity continues along those same lines, though pursuing a contrary tack to popular thinking.  Despite the growing popularity of stripped down, simple designs, Norman argues that simplicity is not always the right direction to take for a design.

Norman references Tessler's law of the conservation of complexity, which states that every application has an inherent level of irreducible complexity.  The only question is who will have to deal with it: the user or the developer.

He argues for a moderate view saying that some complexity is OK, even preferred.  Objects that are too simple can be boring, while things that are too complex are confusing or upsetting.

This discussion of simple versus complex is playing out now in the mobile software space.  Sophia Voychehovski, a UX designer for Turner, says the idea that mobile users are 'on-the-go' and therefore don't want or need the capabilities of the desktop site on their mobile device is false.

She said that users today don't want or prefer a stripped down version for mobile.  They don't want things simple in this context...they want equivalent functionality presented in an intuitive way.

Going further, overly simplified software also faces the danger of feeling too flimsy.  The lean startup concept of the minimally viable product has led to a series of software attempts that are flashy yet flimsy in the hope of attracting further funding.  In some cases, I find that overly simplified interfaces seem to feel more gimmicky than elegant.

It can be too easy for companies to see the work of Google and Apple and assume that a stripped down interface is what symbolizes a modern company.  Their examples, while simplified, reflect deep design work that caters to the well-researched needs of users...and the requisite complexity is just a layer or two away for those experienced users that crave the ability to tinker with the specifics.

Life has no error messages, Norman points out, and in this way software should emulate life more closely.  In life, if you try to fill a five gallon bucket with eight gallons of water, it'll overflow and you'll see water spill out.  There is no error message, you just see the result in front of you.  Instead of scolding the user for not following the parameters of its software, well-designed code should assist the user in how best to continue.

It is specifically in that moment, right as the user has taken a mis-step that they are most receptive to learning: they can learn best when they face the need to learn.

This reminds me of the implementation model Alan Cooper discusses, in which a software interface reflects the inner processes of the software instead of presenting only those options that correlate with what the majority of users are trying to accomplish.  The two men's ideas taken together advocate for software that helps users complete their goals while reflecting the requisite complexity behind the tool being used.

Striking that balance between elegant simplicity and overwhelming detail continues to be a challenge for user experience designers, and Norman's book helps to crystallize those issues into a continuing discussion of the merits of each.

The Inmates are Running the Asylum

Alan Cooper begins with a clear analogy: in all other construction disciplines the architects and engineers plan the construction strategy and the craftsmen execute that strategy.   It is only in software that the craftsman is also the architect.

This becomes the basis for his premise that The Inmates are Running the Asylum. Cooper argues that we are deficient in our development process, not the development tools themselves.

"Programmers aren't evil" he insists, "they work hard to make their software easy to use.  Unfortunately their frame of reference is themselves, so they only make it easy for other software engineers, not for normal human beings."

Alan Cooper, being a former software developer himself, discusses why he believes software developers ill equipped to design usable software:

Clearly, one side of software - the inside - must be written with technical expertise and sensitivity to the needs of computers.  But equally clear, the other side of the software - the outside - must be written with social expertise and sensitivity to the needs of people.  It is my contention that programmers can do the former, but it takes interaction designers to do the latter.

The intuitive thinking here is that since developers know the software at it's most granular, then would be best equipped to ferret out usability concerns.  While intuitive, Cooper shows the fallacy of the argument throughout the book.  The skills that make for excellent programmers are not complementary to those needed to uncover and address usability issues.

Software developers (who he refers to as Homo Logicus) are different from normal humans.  Cooper defines the specific characteristics that make for great software developers work against them when trying to address usability issues.  For example, developers:

• trade simplicity for control
• exchange success for understanding
• focus on what is possible to the exclusion of what is probable
• act like jocks

On the third point he says that obsession with edge cases makes great programmers, but poor usability.  Normal people care most about likely uses/situations, "whereas programming is defined by cases at the edge of the paradigm, design is defined at the center."

I've found that it can often be easy to be lulled into the belief that working with a product on a daily basis means that you instantly know how new people will use it.  While it's tempting to believe that's true, it's also completely wrong.

Jared Spool says that the best companies (Apple, Disney, Netflix among others) are great companies because of their focus on feedback among other things.  He says he tests companies by asking random employees if, in the last 6 weeks, they have spent at least 2 hours watching someone using your design, or a competitor's design.  He asks this of everyone who influences the design.  Not just programmers or usability experts, but the entire team.

Great companies realize how easy it is to lose focus on what your users go through, and these sessions provide the opportunity for everyone on the product to see how people interact with it.  It's crucial to have people from all over the company participate, because those people will notice something that the UX team or the developers may miss from being buried in the details.

While the details can make something ordinary into something transcendent, they can also narrow your focus so much as to lose site of the broader picture.  It's crucial to have developers who obsess over those details...great developers have the genetic code that replays the details of a problem over and over again until the solution works itself out...but that same characteristic can also lead you lose sight of what's important: how typical customers interact with your product.

And no amount of brilliant design can bring back a customer who has tried and been turned off by your product.

Alan Cooper on Agile

I'm reading Alan Cooper's The Inmates are Running the Asylum, and his outlook on the use (or mis-use) of agile was especially poignant to me.

Alan Cooper, like many other designers, views agile as a potentially valuable, though horribly misused process.  The use of agile methodology as a reason to just throw features at users and let them design your product is insulting, inefficient, and ineffective.  If the design isn't done before the programming starts it will never have much effect.

"Just because customer feedback improves your understanding of your product or service, you cannot then deduce that it is efficient, cheap, or even effective to toss random features at your customers and see which ones are liked and which ones are disliked... 

[This manager believes] that his customers don't mind plowing through his guesses to do his design work for him.  There might be lots of ["power users"] who are willing to help this lazy executive figure out his business, but how many struggling [average users] did he alienate with that haughty attitude? 

As he posted sketchy version after sketchy version of his site, reacting only to those people with the stamina to return to it, how many customers did he lose permanently? 

...The biggest drawback, of course, is that you immediate scare away all [the average users], and your only remaining users will be ["power users"].  This seriously skews the nature and quality of your feedback, condemning you to a clientele of technoid ["power users"], which is a relatively small segment. 

I am not saying that you cannot learn from trial and error, but those trials should be informed by something more than random chance and should begin from a well-thought-out solution, not an overnight hack.  Otherwise it's just giving lazy or ignorant businesspeople license to abuse customers."

Design, he argues, is tasked with creating a product that can be built and perform well; that can be distributed and sold profitably, and that makes a success by being something people really want.

Far too often the paradigm of agile is used as an excuse for managers to get more code quickly...somehow arguing that lean practices and agile methodology are good reasons to forgo the crucial work of considerate thought and design.

These people, while acting on a good faith basis to prevent over-analysis and reams of documents from delaying the actual development work on a project, have failed in the other direction: no planning and no documents at all.  While well intentioned, this is the same mistake just taken to the opposite, perverse extreme.

This is not an improvement, or striking a bold step toward progress...it is blindly fumbling your way toward completion, making completely avoidable mistakes along the way.  I think Cooper encapsulates that nicely in the above selection.