practical design

Clients invariably come to us with an simple problem; 

"Our intranet is too hard to use.  This page is broken, this tool doesn't really work quite right...." 

I'm sure you've heard this as many times as I have.

So...we take a look at our data (Knowledge), we look at what we've learned from talking to the client (Comprehension), then we solve the problems that they weren't able to articulate (Application).

What they really meant to say was that the algorithm they had been using to determine the next stage of the lifecycle only works for 70% of the population, and we need to make sure it works for 90%.  That page that was broken really needs to be a whole new tool in the application, and the application doesn't really support their workflow.

Now that we understand their data we can use it to solve their problems.  But if we haven't gone through the act of listening and collecting good information (data), then we won't be able to make that leap to solve the problems they don't know they have.

I find that this is what really separates a good developer, manager, designer from the ones that are just OK.

The good developer goes beyond the spec, and wants to understand why this understanding will lead to a better application of the information you've received.  If you've worked on a team, and you frequently receive or generate specs, how often are those specs right the very first draft?  Specs are complete when we stop asking questions, not when we've found all the answers.

How does all of this relate back to our website, our application?  The good websites take that information, say...our movie preferences, and give us a list of what other people who liked our favorite movies watched.

Netflix (and Amazon, and Walmart, and your local grocery store), does this all the time.  They give the user new information to make informed decisions.  The user is learning new information that allows them to solve a problem:  "What movie do I put in my queue next?".

The user solves the problem, so they are applying the information you have presented to them, just as you applied your data to a new problem by showing a user what similar users were doing....and you never even had to change the data.  Nice.

However, if you can extrapolate what that data means, you are performing valuable Analysis...

Information architecture is the art (or science) of going beyond the data your client presents you with.  As a consultant, a vendor, or an in-house developer (or designer), we have to truly understand the information given to us by our clients.

Good websites can organize information in a way that makes it easier to find what users a re looking for (when they might not know what it is they're looking for).  When I teach design for developers, I spend a lot of time talking about understanding the information in your website.  How do you know what will make your client happy?  Ask questions, many questions, take notes, revisit and revise.

Comprehension goes beyond your statements of fact.  When you comprehend the data you are using, you begin to see the patterns behind the chaos.  Comprehension is the thing that your high school English teacher was looking for to prove that you read the book, not the Cliff's Notes.

Knowledge gives us the facts, comprehension allows you to organize your data, provide tools to compare and contrast it.  Your job is to now impart your new-found knowledge of your client's information to their users (which are oftentimes the clients themselves).

All reporting applications/tools break ground into the realm of comprehension.  What do those sales figures really mean, anyway?  If I compare them to numbers from the last five years, I have a good foundation to view the trends in those years.  I can analyze the facts that correspond to those trends to explain times of growth or contraction.

If I then use my application to display that information, I am providing an essential service for their business.  Instantly displaying analysis that might have taken them weeks to generate in excel.

But, of course, we can take it a step further...

I'd like to begin our look at Bloom's heirarchy with the Cognitive domain because it has the strongest correlation to what we do every day as developers.  Convey information.

Although we may have fancy Flash animations, and slick Flex applications powering our websites and online applications, but in the end, what we really do is disseminate information.  Text.  Facts and figures. 

The foundation of a good application or website is to have the best data.  Collect the most data.  Have the most content.  Attract the brightest minds (or at least the most active in your community).

A good example of a web application with good data (and lots of it) is Craigslist.  Craigslist has provided an excellent service by attracting hordes of people to use it's site for free. This user supported model results in lots of relevant data for users to consume and act upon.

The way it presents the information is simple.  Text and photos.  Just the facts.

Craig's knowledge of stuff for sale is excellent, and he presents that knowledge to us.

This presentation of information speaks to Craigslist's ability to collect, store and present data.  It's really nothing more than a big database interface.  It does not perform complex analysis, it does not market to us, recommend content or toast our bread.  It presents good data in a clear and concise manner (information architecture at work).

When I speak at conferences and user groups, the first thing that I usually hear is..."Sure, that design and architecture stuff is great and all, but I have this amazing application.  Google doesn't have to worry about architecture.  Craigslist doesn't have to worry about design."

Google's algorithms ARE it's architecture.  It's just behind the scenes.

Sadly, although we all may aspire to be the next Google, Microsoft or even Twitter, the chances are we will not have that perfect storm of events. 

Google doesn't have to worry about design because it has the best data.  The information at Google's core is the best in the business.  It's highly accurate, reliable, and it makes people money.  Google got to this position by hiring the highest concentration of PhD's of any private corporation in the world.

So, unless you have deep pockets to hire the next Nobel Prize winner, most of our websites and applications will have stiff competition, and that will take us to our next session on: 

Comprehension:  Patterns in  the noise.

Please comment here to let me know what you thought of my talk, spark conversation, etc.

Take a look at my "Heirarchy of Learning" teaser, and let me know if you want to hear more!!

Enjoy the rest of the conference!
Dave Powell

Today I'm starting a series of posts on what is missing from most website design today.  Meaning.

When I speak on introductory design, or "Design for Developers" at conferences like CFUnited, I frequently mention the word connotation.

Why is connotation so important?  In a field where we so often speak of simplicity as a virtue, we often overlook the fact that the human mind was meant for more than just the obvious display of facts.

Sometimes, the goal is to convey a deeper analysis of information, sometimes it is to convey a sense of emotion...or perhaps, both.

So, to spark a deeper discussion about the merits of complexity, let's start with Bloom's Taxonomy of Educational Objectives.

The Taxonomy was intended as a method for analyzing and improving educational method, but it is a useful tool for measuring and improving communications of all kinds.

Bloom  divides his taxonomy into three sections: affective, cognitive and psychomotor.  We'll  avoid the psychos for now and focus primarily on the affective and cognitive hierarchies.

The affective hierarchy applies directly to front-end design, while the cognitive hierarchy can be applied to application interface design.

In my next entry, I'll discuss the affective heirarchy, and how it equates to the art and science of web design.

Again, this is not something you hear every day in our line of work, but I think you'll eventually agree.  There is something to be said for this learning stuff.  After all, what else are websites for, but educating your audience/users?

While looking for a topic for today's blog post, I began to muse about the difficulties facing someone trying to find new ideas floating around in the blogosphere. 

That train of thought led me to question how it was that I ever got along without the web.  How many of us in the creative and development fields actually come up with an idea (or code base) from scratch these days?  A majority of blog posts are like threads on a listserv.  Half either refer to, refute or otherwise reference other blog posts.

Despite the breadth of information on the web, this would seem to limit the variety of content on the web today.  Especially since we are all creatures of habit, rarely straying from the "usual" sources of online information.

So, here's a new practice that I will endeavor to implement: 

One day a week, I will unplug (I usually do this on Saturdays whenever possible).  Sometime during this day, I will spend one hour brainstorming about ideas for the Practical Design blog.

I need to remind myself that there are plenty of things to discuss that aren't being blogged about.  In fact, many times, those are the ones that really need to be blogged about!

Next weekend, I'll write about my latest and greatest unplugged idea.  See you on the other side.

Repost from the old blog from June of 2008:

Stephanie Sullivan just posted a great article on the Community MX blog about the discussion floating around in the blogosphere (primarily 37 signals) about the need for designers to become developers and developers to become designers.

I humbly ask...why can't we all just get along?? 

This is my reply that won't post to the Community MX website:

I agree with pretty much everything Stephanie says here.  (and yes, I too am late to the D vs. D blog boat)

There's a good reason everybody's talking about this.  It's a risk area for every web or interactive project, and reconciling the differences between the creative and technical project team can seem insurmountable in many circumstances.

In my estimation, as with many things on a project, success hinges upon good communication.  With the client, and certainly amongst those doing the work.

I spoke on the subject of Design for Developers at CFUnited last week in DC.  I feel that only by enabling designers and developers with a base of common knowledge can we hope to make successful web sites and applications.

It also seems to me that we are experiencing a paradigm shift of sorts.  The web presence is evolving.  No longer are we working strictly on web pages that are presented in a static manner.  That's fairly simple for a print designer to learn. 

With the advent of the RIA (be it Flash, Flex or AJAX), we have a new breed of specialist.  The User Interface/User Experience Designer/Developer.

The UI/UX designer is in high demand these days.  Is this a matter of circumstance perpetuated by tools that don't quite bridge the gap?  Will the UX developer go the way of the Dodo with the development of smarter tools like Dreamweaver CS4 and Adobe's Thermo project?

Only time will tell, but one constant will remain.  Those that have the foundation, the skills, to bridge the gap between design and development will continue to do well for themselves.

Finally got rid of Blogger!

I know, I know, I should be using BlogCFC, and I will be for some other projects...but I wanted to have a few more resources at my disposal for the Practical Design site, including the ability to have plugins, static pages and all that nice stuff.

Plus, I've been wanting an excuse for playing around with some MT skins.  ;o)

So, thanks for those of you who are checking this out for the first time!