Marketer and blogger Douglas Karr has another take on the issue, comparing the bubble concept to one of his daughter’s friends who filters her worldview based on news she receives from Facebook, CNN, and Jon Stewart.

Watch the TED video and read more

I got to thinking: how does the so-called filter bubble cascade down to web design?  My conclusion was drawn from the very end of Pariser’s TED talk: choice, and control.

Pariser’s argument was that, unbeknownst to him, Facebook was deliberately filtering out comments from his opposing-view conservative friends in his News feed simply because his Facebook-searching habits tended to sway more to the left.  In other words, Facebook’s opaque algorithms filtered what he saw based on what it believed he believed.

The better experience, he argues, is to give web users choice: just as we have the choice which conservative- or liberal-leaning newspaper or online magazine we might pick up, web experiences must empower us to decide what we want to filter.  Remove the filter power from dispassionate, uninformed algorithms, and you arguably remove the ‘me’ bubble.

I’ll be applying this theory to an upcoming project.  Rather than forcing users to see geographic search results I’ve told the search algorithm to choose and display, instead I’ll be thinking about giving users the choice to select what they want to see in other geographies: combine convenience with control.

WordPress theme designer Curt Ziegler’s recent Webdesign tuts+ article hits on all those and more.  His vision: a usable web presence free of unnecessary clutter.

Fighting the battle against clutter is something every designer undertakes, whether it’s on their own site or when designing for a client. Your web site’s design should enhance your site’s purpose by putting the focus on the content and being usable by everyone. Taking the extra time to ensure no detail is left overlooked will produce an effective and attractive website.

To me it means a ‘back to basics’ approach to design.  Any design.  Web, mobile, paper, whatever your canvas.

Last Saturday, I watched the Florida State vs. Miami football game and heard Kirk Herbstreit mention blocking-and-tackling fundamentals as a core reason why the Seminoles demolished the Canes in their own backyard.

What does that mean?  Of course they were blocking and tackling.  Isn’t that a given?  The very essence of the sport?  Why bring it up?

Because so many team lose sight of the basics.  So many teams win with flash and pizazz that they lose sight of what wins championships: a fundamental approach to the things that teams must not un-learn without the risk of implosion.

I can hear my high school football coach now: wrap up!  Translation: tackling isn’t worth a damn if you can’t square your body to the runner, hit low, and wrap your arms around him with opposite force.  It’s one of the first lessons in pee-wee football, but one of the easiest to lose sight of, to un-learn.

The blocking and tackling of design

In much the same way, we lose sight of the purpose behind our designs.  Ad revenue, ‘filler’ content, SEO, sometimes the very functionality itself, gets in the way of user-centered design.

That’s why, every few months, I pull out one of the most trusted texts I ever bought when first learning the fundamentals, The Non-Designer’s Design Book, by Robin Williams.

What Ziegler writes is reflective of Williams’ core principles:

1. Contrast: often the most important visual attraction on a page.  If elements are not the same, make them look very different
2. Repetition: repeat visual elements of the design throughout to develop organization and strengthen unity
3. Alignment: place nothing on a page arbitrarily.  Make every element have an intended connection to one another
4. Proximity: related items should be grouped closely to organize information, reduce clutter, and provide clear structure.

Such simple principles with such profound effects on our work.  Yet, at the same time, so easy to lose sight of them as we develop our requirements and refine our craft.

Stay basic my friends…blocking and tackling….

see more Very Demotivational

All bad things, sure.  Whether you buy into the reports and dire straits of Mother Earth or not is really not the issue for me.  Lately, I find myself avoiding the home page at all cost.  The news appears so bad I literally feel myself getting stressed out when I arrive there.

The Weather.com Home Page Feature Section

When did the Weather Channel stop reporting the weather?

At the same time that news outlets stopped writing news I guess. Like most widely used sites, weather.com has been slowly evolving since its inception.  Look back and you’ll see their home page features morph from fact-based to sensational. 

As their corporate machine – the Weather Channel, once proudly independent is now owned in part by NBC Universal -  focuses more on controversial media and advertising and less on what’s happening in your backyard.

Don’t get me wrong: there are several aspects of the new site I really like.  Larger font, asynchronous weather fetching, clearer interaction on the main nav bar, to name a few.

I guess I just miss the old days, when weather.com’s home page simply gave me, well, the weather.

To be sure, it’s an elementary-looking overview widget with late-90s era visuals.  But it was the first thing seen on the home page, the most important piece of news on the site.  It answered the fundamental question on everyone’s mind, “Sunscreen or umbrella?”

At the risk of sounding both nostalgic and cynical a la grandpa’s back-when-I-was-your-age quips, I’ll simply end by saying, the best sites to me are the ones that stick to core competencies. Part of being ‘simple’ is being honest.  Penning climate change on a weather site, while related, is off track.

I welcome your opinions, both in support and in refute.  But please keep them clean and not mean.  Bloggers are people too.

I’m always looking for research on agile practices, specifically as it relates to web design & front-end development (HTML, CSS, JavaScript).

Quite frankly, not a ton exists. SCRUM, an agile methodology, was originally geared to the software world, so I find that most research pertaining to it has a developmental flavor. Nothing wrong with that of course. Just not entirely applicable to web design and development.

Here are 12 valuable resources that specifically call out agile in the context of web design and user-centered design:

1. Just Build It: HTML Prototyping and Agile Development, by Garrett Dimon.  More of an entry on prototyping than agile itself, but it aligns to a main principle of the agile manifesto: working software [code?] is the primary measure of progress.
2. Waterfall Bad, Washing Machine Good (MP3), by Lisa Reicheit.  There is a commonly held belief that Agile methods and user-centered design do not play nicely together.  On the contrary, Agile and UCD can be combined for mutual benefit.
3. Case Study of agile and UCD working together, by James Kelway.  This case study shows how the ComputerWeekly user experience team integrated with an agile development group.  Blogger's note: I didn't find their work to truly align to an agile methodology, but pay attention to the role of the 'boundary spanner,' aka scrum master.
4. Bringing User Centered Design to the Agile Environment, by Anthony Colfelt.  Fantastic article on the pitfalls of Agile and the integration of traditional UCD.
5. Research from the Agile Alliance.  10 useful articles on usability, use case development, interaction design, and UCD process, all pertaining to the incorporation of agile principles:
   • Introduction to Agile Usability: User Experience Activities on Agile Development Projects
   • User Centered Design and Agile Development of IT Systems
   • Interaction Design Meets Agility (PDF)
   • Agile Development Methodologies: A Catalyst to Success (PDF)
   • Process Agility and Software Usability: Toward Lightweight Usage-Centered Design (PDF)
   • Scenarios, Tall Tales, and Stories: Extreme Programming the Oak Grove Way (PDF)
   • Telling Stories and User Role Modeling

Todd Zaki Warfel

I attended Todd Zaki Warfel’s webcast on prototyping last week.  Hosted by our good friends at UIE, the seminar focused on the principles behind creating informative, useful web-based prototypes.  It’s a fantastic primer, and I encourage anyone who’s interested in learning more about prototyping to grab a (legit) copy of the session from UIE.

I’m not going to reveal all of Todd’s key principles (watch the webcast!), but I do want to hit on several that I like to incorporate into my own work methodologies at ProjectEric.com.

(Some of) Todd’s key principles

1. Plan a little – prototype the rest.  First, let’s be honest: prototyping can be a lot of fun. Too much planning takes the fun out of it.  Whether your prototype is a paper model or a high-fidelity, HTML-based masterpiece, part of the fun of prototyping is the ability to learn-fail-learn-apply very quickly.  Too much planning impedes the natural art of tinkering. At ProjectEric.com, I like to keep my workflow very loose.  Key milestones towards completion, a broad sense of what I want to get accomplished sprint by sprint.  Then, I just let creativity take over.
2. Explore concepts & make progress.  Prototyping is exploring.  For instance, I’ll log into JQuery, find a few good scripts that loosely accomplish the primary function(s) I’m trying to get across, then I might create several different mini-prototypes based on each script I find.  Take navigation: there are lots of solid JQuery-based techniques.  I’ll find my favorite two or three, then I’ll enter in the navigation items I think the client wants, make sure it aligns to my overall architectural plan, then I let ‘er rip.  The client gets to see each option; that way, they instantly become part of the prototyping process.  Plus, with prototyping, I reduce that often dreaded request from clients: “Show me 4-5 screen comps.” Ugh….
3. Explore a direction.  In particular, a user direction (or use case).  Too often, I see designers prototyping the whole experience, end to end.  Instead of a discovery/learning mechanism, prototyping becomes nothing more than a spec – like a detailed wireframe – from which developers code.  No, prototyping is more powerful than that. Explore the unexplored when putting together a prototype.  Take the hardest user flow (or use case) and prototype just that.  You can fill in the undeveloped areas around the use case with filler images or square boxes.  That way, you can focus on the most challenging aspects of the project by way of prototype and filter the easy stuff out (e.g. I may not need to prototype the footer; I may choose to leave it out entirely or fill it in with a placeholder image).  You can always spec the remainder of your work (the non-prototype stuff) in a wireframe.
4. Get your hands dirty. Many designers I’ve met have an insatiable need to be perfect the first time.  Probably all that client rejection, year after year.  Prototyping is dirty.  The dirtier, the funner.  It’s one of the reasons I sometimes choose not to develop prototypes using HTML/CSS/JavaScript.  I find that too often the code locks me into a design idea, rather than the other way around.  Lately, I’ve been using Fireworks CS4 to put my ideas together in a sort-of clickable model.  It’s forgiving, it’s easy to move elements around on the page, no code required.  What’s better, I can often prototype in real-time at a client meeting, have them give me immediate feedback, then I can turn around and make changes before the meeting adjourns.  (Oh, and that reminds me, do make mistakes in front of your client.  You’re human.  They want to see you trying ideas.  Rarely do I meet clients that expect perfection the first time.  If they do, consider taking them off your client list.)

Key Web Design Milestones

I have to admit.  In the last few years, I’ve grown to loathe, despise, hate, the word ‘process.’

Process: deal with in a routine way; a particular course of action intended to achieve a result; programmed instructions in order to obtain the required information.

Process, by its very definition, breeds controlled routine.  Repeatability for consistency’s sake.  It aims for efficiency.  But are prescribed processes inherently efficient ways to work?  It’s an interesting premise, especially in web design where work must remain nimble, creative, and non-conformist.

As someone who sits on the fence - I manage a standards team, and at the same time, am a web designer in my own right – the battle in my head is constant: I can re-use some existing design process from a previously successful project in the hopes that I’ll score a home run, or I can look at the task at hand and simply just do what comes naturally.  No rules, no boundaries.  Just execution for the sake of execution.

Methodology: A system of principles, practices, and procedures applied to a specific branch of knowledge.

Note the missing evil word, process.  I’ve found that methodological principles are a much better way to attack a web design challenge.

Every projects’ scope is different.  Time, cost, and resources are rarely the same from initiative to initiative.  So why treat your design plan in a one-size-fits-all format?  Why create the same design process for projects you know will be variable?

In contrast, a methodology promotes ideas like frameworks and principles.  Think of them as higher level ideas on how to approach a design challenge.  They’re looser, more forgiving, more flexible.  Easier to tailor to the challenge at hand.

Examples

• A standard UCD process, specifically the Implementation or Deploy phase.  Seriously.  Will I ever follow this process the exact same way, over and over again?  Not likely.  Is this a good example of executing a project?  Sure.  Is it useful to follow this line-by-line, in a literal interpretation, for every project I deploy?  Certainly not.
• A UCD methodology.  Broad, persona-based, flexible to handle all kinds of projects.  I like starting with this kind of documentation to build my plan, rather than utilizing a prescriptive process like the one above.  I know the who, what, and generally speaking, the when.
• An agile methodology (video).  I like SCRUM because it hones in on common threads that most projects live by: time, scope, resources, and communication.  And in this particular methodology, it shows how you can break up the scope in fast-paced sprints.  Rules of thumb, yes.  Prescriptive process, no.

Web Design from Scratch

Couldn’t be a more appropriate and targeted vision statement for ProjectEric.com.  It’s what I strive to produce in all my designs, whether I’m working with a team or individually:

“Keeping it simple is hard. One reason it’s hard is because we so often feel compelled to be doing something “more”, to be different in order to keep the visitor interested. That’s how cleverness creeps in. When you’re creating your web site this little voice can start telling you that it’s too boring, too much like the next site. You feel a desperate need to come up with something with a bit more jazz.”

Members of large design companies or institutions find this quite troubling.  After all, they were hired specifically for the purpose of being creative.  Creativity breeds new stuff.  New stuff makes its way onto a site.  Over time, your site starts to look like a Christmas tree, all lit up with various colors, placements, font types, mindless stock photos, you name it.

So, why have so many designers on staff?  Why not have a few designers, tasking them to simply push conventions, standards, best practices, thus minimizing net new design?

If you buy into “less is more,” then your answer to the last two questions might be, “Darn tootin.”

But I look at it a different way.  Certainly, design conventions breed simplicity.  Consistency.  Ease of use.  I should know; I currently manage a style guide for more than 100 designers.

Don’t Knock It Until You Try It

I never knock “new.”  New breeds fun, enlightenment, creativity, and most importantly, personal satisfaction.  It’s how you apply “new” that’s important.

Consider a new button.  Simple enough.  Let’s say all of the buttons on your site are blue with white text, and the so-called new idea is a red button with white text that changes color as you hover.  Is the idea really new?  Certainly, the basic interaction pattern of a button isn’t.  They’ve been in the web world for years, linking users to an action.  But the introduction of a red button for your site is novel.  Never been done before.  You’re a blue guy.  What’s with this hippie designer thinking red is better?

Indeed, the red button may not be the right solution.  Does it stand out?  Against all the other blue buttons on the page, certainly.  But does it need to stand out; that’s the question.  Why are you trying to communicate to your customer?  What are you driving your customer to do?  How might a red button impact all the other content on the page?  How might a customer treat the meaning of red against blue, in their mind’s eye?

Too often marketers equate “new” with “increased click-through rates” or “higher conversion rates.”  While this is sometimes true, it might sacrifice other important user experience principles: consistency, brand recognition, and organization, to name a few.

Arguments for Both Sides

So it’s painfully clear: “new” is a powerful word.  It means change, opportunity, but potentially degradation as “Save the Pixel” explains.  New ideas are always positive.  It’s how they’re implemented that counts.

I run into recent college grads every now and then.  They’re excited.  Passionate.  A bit naïve.  But willing to roll up their sleeves and enter adulthood.

I love their optimism.  As I get older, I find myself saying “That’ll never work” too many times throughout the week (at least I recognize it).  They enter the work world with fresh eyes, new ideas, and a healthy sense of entitlement that only Gen-Yers can pull off.

But I see — too many times — an “I can” spirit with an “I don’t have the right skills” set of credentials.  I’m not talking about just work-world experience.  Granted, too many big firms today attempt (expect?) to hire newly-minted college alumni and at the same time, expect each one to possess a portfolio of a 10-year veteran.

No, I’m talkin bout skillz. Game.  That thing that tells an employer, “Yes, this guy (or girl) has it.“  It’s that right balance of designer, developer, project manager, theoretical, user-centered IT.

Consider this recent job posting…

Fieldglass, Inc, the leading provider of services procurement software, is seeking a Web Designer-Developer to maintain and broaden the Fieldglass identity in corporate Web mediums as well as some offline creative materials. The position involves the back end programming and front end design and implementation to create an exceptional user experience.

And this one…

Cyclingnews is looking for a talented web designer to work across our group of cycling websites.  We’re looking for a designer/ developer with substantial work in user experience, interaction design and wireframing, and a current portfolio that demonstrates a strong understanding of online design. With solid experience of using Photoshop, you will have an appreciation and flair for design and branding. A good knowledge of HTML, JavaScript and CSS is essential, as well as some experience of PHP sites.

Notice something?

Take a look again.  New role.  Designer-developer.

Yet, many traditional higher-ed institutions offer a focus in one or the other.  Graphic design vs. computer science.  Art vs. code.  Liberal arts vs. bachelors of science.  Too many interviewees have one, or the other.  Rarely both.

Some of the more successful institutions offer graduate degrees that combine the artistic with the technical.  My alma mater, Florida State, used to offer a concentration in Interactive and New Communication Technologies.  It combined graphic arts with code.  It has since been incorporated into a media production-focused program, but word has it that it’s about to be distinctive yet again.

That’s a good thing.  If these job postings are any indication, the wave of the future for web-focused graduates is to combine the best of both worlds: the touchy-feely with the analytical programming.  As ad agencies shrink to stay efficient and big companies churn out more with less, the name of the game is know it all.  Be more well-rounded.  Vary your skillz.

The days of the interaction designer who can only wire frame, the visual designer who can only work in Photoshop, and the editor who can only write, are over.  Long live the designer-developer….

3 Web Design Planning Mistakes

I’ve been a part of some fairly large projects in the past that – how can I say – missed the execution mark.  Slipped milestones, cost overages, scope creep.  You name it.  I’ve witnessed it.  It’s web design; wild results come with the territory.

The misses occurred, not because of lack of execution, but because of undocumented execution.

To be sure, everyone understood the basics: when major milestones needed to be hit, when design reviews were to take place, how many resources needed to be assigned.

The devil is in the details

What we found was more subtle.  We simply never wrote the details down.  We expected things of each other.

Here are my favorite three subtle project management details that can lead to pain if not caught early. From what I could tell, had we simply written some of these expectations down – and of course, had the project manager enforced them – who knows how much time, cost, scope and Aspirin could’ve been saved.

Define the Audience in the Briefing Stage, Not the Design Planning Stage
I’ve worked on several projects where the design director asks questions of the end user demographics after a design brief has been created.

That’s backwards.  Understand the audience to understand the design parameters (among other things).  A good example: what paragraph font base would you choose if your end users were 65+ as opposed to 18-30?  Granted, that’s an extreme example, but proper end-user analysis informs the design planning phase, not the other way around.

Define File Formats in the Statement of Work (If Possible)
JPEG, GIF, or PNG images?  MOV, FLV, or MPEG videos?  Yes, it’s a big deal to not have them defined.  No, you shouldn’t wait until you’re loading them into the system for the first time before deciding what format to use.

I expected that the videographer was going to deliver Flash video in FLV format for me to plug into the site.  I had a perfect Flash player to utilize: easy to incorporate, configurable design, and it loaded quickly on run-time.  Instead, I received 100 MPEG files, the one format that this player didn’t support.  I had a choice: find a new player, or ask the video guy to re-format all 100 files.  Had we simply decided up front, it could have saved me 10 hours finding a new player that was just as configurable as the original.

Content Writing Is a Separate Milestone
Many clients I work with believe that all writing is ‘webbable.’  In other words, documentation recovered from company PR documents or print marketing material can simply be converted to HTML word-for-word.  Not only is this ill-advised, it’s the worst way to look at content writing for the web.

Web writing is unique: it must be scan-able, concise, and easily readable.  To accomplish that, treat web writing as a separate milestone in your project plan.  Planning to ‘import’ editorial into the development phase of any web project is doing your client a disservice.  Don’t expect writing (whether it be web writing or writing ‘importation’) to occur as the last pixel is being put in place.

I’d hate for your marketing site to sound like this!