That definition works on my computer! … </tumbleweed>

There’s a lot of opportunity in that definition for “but what does that really mean” responses. It makes sense on its own, but when applied to your context of work, how does it fit? I think the problem is that most people don’t know how it fits. They don’t know who the users are so they can’t be specified. They don’t know what the goals are so those can’t be specified. And how can they make sure something is effective, efficient, and satisfying?

Get someone from Usability to look at it! Of course, you might not have someone from Usability available, or at all. Or have time to do usability testing. Or user research. Or, or, or. Most companies have this problem to some extent. Developers are often left on their own to figure things out and I suspect that’s the impetus of 3 Simple Usability Tips For Developers.

Jesper specifically asked me (and others, I’m not that special) to respond to his post and since I know my response won’t fit in a comment box… here we go…

Everyone Cares About Usability

Everyone cares, to some extent, about usability. “Good” usability means happy customers, silent support phones (ha!), and heaping great wodges of cash in the biscuit barrel. Who doesn’t care about that! No one, that’s who.

The problem, as ever, is no one speaks about usability in the same way. So Jesper boiled down the ISO definition of Usability to something simpler:

A usable system is easy to use, easy to learn, and difficult to make mistakes [with/on].

I have no issue with Jesper’s boiling down-ed-ness, but I think it does just that: boil down. As tips specifically for developers, I think different jargon is in order. Now, now… I know we Usability peeps are supposed to avoid jargon, but when you have a (relatively) singular audience, you design your system with their language in mind. Here’s how I would re-jargonize (man, I am making up words left and right today) the definition of Usability for developers:

I’ll give you a bonus if you make software that meets our customers needs, is coded as simply and securely as possible, has no known bugs, and works the same way on all the platforms we support.

I put the bonus part in there because I believe developers need incentive. The bonus could be doughnuts, not necessarily cash.

Meets our customers needs. You can see this in the current definition of Usability, but I believe when put this way, a developer that you want working for you will ask, “Who are our customers and what do they want.” And by gum if a developer ever asks you that you’d better kiss them (don’t actually kiss them). The easiest way to find out what people want is to ask them. Surprisingly, they usually want to tell you.

Coded simply and securely. You want the simplest solution possible to the problem. Most of the developers I’ve seen tend to write 30 lines of code when 3 would suffice. Create an environment where elegantly coded solutions are more valuable than crap code. But you also want secure code, so no PHP. If you have a situation where you have to choose between simple and secure, make sure you communicate what’s more important given the context. To figure out the context, see previous paragraph.

No known bugs. No bugs is a pipe dream. There will always be bugs in software. If you test all cases you’ll never ship, so go for no known bugs. Shipping with no known bugs means you need to have a good stock of test cases to work from. To get good test cases you need good use cases. “How will people use this software? Let’s test it to make sure it works like that!” To get good use cases, see the paragraph above the one above this one.

All platforms. I throw this one in because web development is becoming so prominent. Companies are relying more and more on the web to make money and get things done. That means more web apps and most of those web apps are being written by life-long COBOL programmers. Choose which platforms (and browsers) you will support and run your test cases on all of them. Listen to your developers when they say it’s not worth testing on anything below IE6. Developers, please start saying it isn’t worth testing on anything below IE6.

What is Usability Really?

Usability is a lot of things and it’s mostly not usability testing.

Bugs in software are a huge problem. Bugs slow down or keep users from completing tasks which costs you money because you didn’t do it right the first time and because the user may not buy your product again. Bugs increase calls to support and even if you offshore this it’s expensive. Bugs are something developers think about.

Now that I think about it, that’s a better definition!

No known bugs.

To get to that point, you have to do a lot of the up front work right. Doing that up front work will often solve (read: not introduce) usability issues.

Shorter Next Time?

Yes, I could have left an, “I agree!” comment on Jepser’s blog.

But I’ve often said I see my job as a translator for all parties involved on a project. I translate what the users want to the business people and the developers. I translate between the business people and the developers. To me, that’s the value of a Usability person. They learn to speak the language of their customers and on a project, everyone’s a customer.

So to developers I say, “no known bugs.” To business people I say, “reduce calls to support,” and “increase sales.” To users I say, “it just works.” To everyone, in some respect, it’s about the end result being useful, usable, and satisfying.

No known bugs are useful because it means you don’t have to fix past mistakes; you can work on new (necessary) functionality. More money is always satisfying. Software, when usable, means your customers don’t even think about your product.

And that’s the best compliment of all.

me: Make it easy to use by everyone. Done and done.
mr. davis: Yeah, okay. If it was that easy, you wouldn’t have a job.
me: It is part of my job to make myself irrelevant.

It is part of my job to make myself irrelevant.

It’s not that I don’t want a job. I very much enjoy getting paid, and so do the people I owe money. I just look forward to a time when my work is done here, wherever “here” is.

When I work on a project, I don’t consider it my job to solely make a usable product or to validate that a product is usable. I also impart my knowledge of Usability (in its broadest sense) to the people I am working with.

I’ve grown up, so to speak, in the corporate world, but I’ve done my share of freelance and small-business client work as well. It’s rare that you ever work truly alone. And if you are not working alone it’s an opportunity to impart your knowledge, or mad skillz if you will, to those you work with. At least, that’s how I see things.

My hope is that the more you know about good design principles (graphic and interaction) the better choices you’ll make on the next project. And if I get you involved interacting with users and it helps you gain some insight, maybe you’ll ask to be involved next time. In a way, what I am trying to do is make your job easier.

I’ve worked with a handful of people over the last 10 years who think the same way I do. They’ve imparted business knowledge and development knowledge to me and it’s allowed me to make better design decisions.

Sure, we all had to be more involved in more activities on the project than our job descriptions defined, but we all knew more and thus made better decisions. At least that was the hope. I’ve found that the more people are involved in the beginning of a project, the less rework tends to happen later in the project. That’s not a new concept by any means, yet most people still resist getting involved early.

There are a number of heuristics that I try to impart to everyone I work with. The more they know about the stuff I know about, the less they’ll need me over time. Does it mean I’ll ever be truly irrelevant? Probably not. But it will mean, and has meant, that I get asked fewer “dumb” questions by the people I work with. I get pulled in to fewer conversations about the order of fields on a screen, or what font size should be used, or if we should add more blue. Okay, I still get that last one regardless of what I do.

Training you to be better at making good design decisions lets me focus on the things that are really complex, or something totally new, or on fixing “legacy” issues. Because of those things, I don’t think I’ll ever be out of a job. But a boy can dream.

It would be nice if everyone just did good design. They don’t. That and Yakob’s voracious publishing over the years on all things duh is what created the need for my position. But I really believe that the more everyone knows about creating things that are useful, usable, and satisfying, the better the world will be.

Yeah yeah. It may be idealistic crap, but I can’t stand knowledge hoarders. The project is to make something cool, not just to write code or requirements. Consider sharing your knowledge and maybe some day you too will become irrelevant.

I had the pleasure (truly) of speaking with Molly Holzschlag, Patrick Haney, Aaron Gustafson, and Steph Troeth today in front of the W3C’s Technical Plenary/Advisory Committee here in Cambridge, MA. Here’s a picture of me and Steph on stage. Really. That’s us.

I had a bit of trepidation about the presentation because I felt a bit out of place. I am not that technical. I fell asleep once reading a specification. Okay, not really, but I am not the target audience for the specifications. That actually worked out well I think, as I should be one of the targets for the specs, or at least considered when specifications are written.

We had a lot of good questions in the room and on the supporting IRC channel that’s running during the event. There were also some asshats commenting on IRC. I guess that comes when you are able to hide behind your computer and talk trash. But that isn’t important. The good thing is that I feel we were well listened to and I think understood. Making that understanding actionable will be the next step.

Overall, I am glad to have been invited to speak in front of this audience (about 300ish, just a guess) and I hope the dialog continues. Based on conversations after the panel and during lunch, and while I listen to some of the other presenters, I think it will.

Some one in the audience wrote a post on the event blog about our panel and some commenting has ensued. Well, 2 so far are from panelists. :) Feel free to give your feedback there. Or here. :)

Jason has chimed in a couple of times in the comments on that thread. I was going to comment too, but decided to post about it because of the length my commentary has reached, desire for traffic, and general damn-I-need-to-post-somethingness.

One thing that Peter wrote caught my eye:

“information architects” typically do a lot more than information architecture.

I think that other “UX”-related professions would say the same thing about themselves. My dayjob is a specialist position. My job title is Interface Designer. But I do a heck of a lot more than just design interfaces. I have to. Simply to be able to get to the point of putting widgets in some semblance of order. It is largely about the preservation of my sanity that I get involved in so many aspects of requirements, design, development, and testing.

Perhaps it would have been better to throw in a couple more job titles… Thanks to Peter’s “user feedback” and the method by which 37signals is publishing the book, it is an easy update (or iteration if you will, as I view the book as a living document of sorts) to make. If necessary. I am not sure it is.

I know we all have been involved in arguments/debates over job title vs. profession vs. activity. Depending on the make up of your organisation, or more importantly what you value (right or wrong), you may want an Information Architect in your company, or you may want someone to handle the information architecture for the new site. I think, when it comes down to it, the activity is more important than the job title or profession.

Part of the issue resides in the fact there are plenty of people out there who promote themselves as Information Architects, Usability Engineers, or Interaction Designers and really will do only those activities. They’ve been trained and expected by many industries to specialise and not work outside their task checklist. I hate working with people like that because they don’t think they have a responsibility to the user, client, or product; only a responsibility to their tasks.

Overall, I think Peters’ argument about 37signals perceived shallowness is pretty weak. Especially using the generalising phrase of “all of which” to support a single issue argument. If Peter has more issues with 37signals, and this is the straw that broke the camel’s back, then so be it. Perhaps a “Top 10 Reasons Why 37signals is Shallow” list would be a better way to support his statement, “All of which confirms my belief in the shallowness of 37Signals’ views and rhetoric.” I’ve read his site for a while and this seems out of nowhere to me.

Things can obviously be extrapolated to other contexts, but people need to keep in mind that they may not always be able to “Get Real” in the same way 37signals does.

(Jason, based on some of the chats I listened to after your keynote at SXSW, I think, for a while at least, you can’t repeat often enough that these perceived platitudes are from your experience, applied within your context. For some reason, many people seem to think (or maybe they are hoping) you are telling them how solve all their process and development problems. That isn’t the case.)

There is no silver bullet and frankly you probably don’t need one. It is far more important to be able to find the right kind of gun, be able to load the gun, be able to aim the gun, and perhaps most importantly, be able to figure out where the werewolf is. If you are lucky enough to have Marty Feldman* on your team, by all means invest in a silver bullet. Sadly, everyone is SOL on this one.

So spend some time figuring out what your problem is before trying to Get Real with it. Something I am p=>.001 positive that Jason and Peter will agree with. And you agree with it too. Because I said so.

So we are clear, it’s called “being ironic.”

* Since my Marty Feldman reference seems to be a little too obtuse…

Inga: Werewolf!
Dr. Frederick Frankenstein: Werewolf?
Igor: There.
Dr. Frederick Frankenstein: What?
Igor: There, wolf. There, castle.
Dr. Frederick Frankenstein: Why are you talking that way.
Igor: I thought you wanted to.
Dr. Frederick Frankenstein: No, I don’t want to.
Igor: Suit yourself. I’m easy.

Young Frankenstein

I’ve sounded off on this before due to a couple of posts on OK/Cancel and Wodtke’s site. Well a new post and comic are up on the OK/Cancel site today. And being the intorvert who is really an extrovert, I have a response.

Who Owns UX?

Those who sign the paychecks of the people who design and test the product or service in question.

Thank you.

Know the Law. Don’t Be the Law

We designers and usabilityers are like lawyers.

We can identify the risks to business and give them mitigation strategies, but it is up to them to decide what that really want to do. Why? Because it’s their money. If they want to design some software that everyone hates, against your well-reasoned and research-backed conclusions, so be it. Look how many times Microsoft has gone out of business because of the crap they sometimes produce.

We certainly have a serious responsibility toward making the user’s experience a positive one. But the bottom line is that we own nothing, nor should we. The further down the development cycle you are, the less say you have over the decisions made. So if you are a QCer, you basically have no say. Sorry, but that’s just the cycle.

If you want to have more responsibility over the user experience you must position yourself in that sweet spot where those wacky business people sit around and say, “Hey, I gots me an idear!” (Just kidding busifolks, I love ya.) That way you can influence decisions as they are being made. If you are stuck influencing decisions like where to put widget X, you are not contributing much to the user experience.

We are all part of a system of commerce: business, users (ya know… people!), designers, testers, developers, and even project managers. We all influence each other and hopefully are all working toward a better tomorrow today.

But until you are in a position to sign the cheques, you gots nothing but a responsibility to challenge business decisions with research-based knowledge, challenge development choices that could impact the performance of this System of Commerece, challenge users to be better users, and finally challenge yourself to not get in the way.

I love you all, but many of you take this crap waaaay too seriously. Chill. Be curious. Help people. Think big. Own nothing but a good work ethic and a desire to learn.

That’s a pretty typical usability objective. Generally speaking, I don’t often care how long a participant takes to complete a usability test task, though I will cut them off after 5 minutes or so. But dealing recently with “performance” people got me thinking.

The performance people were concerned with the performance of the system; that is the computer system. They always ask, “How fast does this need to happen?” Which makes me laugh because the answer is always, “As fast as possibly… in an instant.” Which never really happens.

We all know that those pesky users will notice a change (or lack thereof) after 250ms of taking an action. So I sometimes say to the system performance people, “I need it to paint the new screen in 251 milliseconds.” That makes them laugh. Truth is, for what I spend my time designing, time really isn’t of the essence. I am just looking for things to work quickly.

Quickly is a subjective view of course, which is why we are pushed to put actual timings into our objectives so that when test time arrives we can show to what extent we met the objective. Conceptually I have no problem with this. What I do have a problem with is that I focus on the human element, they focus on the computer system element. Instead we should be focusing on the task element.

Caveat for those who haven’t read here long or in a while: I work in a land where the job of design and development are separated. If these jobs were combined, I don’t think there would be much of a disconnect. The disconnect is easily overcome, but I find after almost 6 years of doing this, the disconnect still exists.

When I first started, I toed the line and added what I thought would be good times to beat in completing a task. But now, even when I am dinged for it, I come back with the defense that building a time-based usability objective is unrealistic as usability objectives are often defined (and rightly so) in the requirements stage of development. The other aspect of performance, the computer system, is not looked at until actual building of the new software. And that too is appropriate. Computer system performance is a technical constraint that must be dealt with on all software dev projects. And you don’t necessarily know what the technical constraints will be until you try to code the dang thing.

There is certainly a constraint based on the user half of the overall System of work, but that is a little more malleable. It also has far many more variables that are impossible to design for completely. The computer system on the other hand has limited variables (in comparison) and it is usually much easier to focus on building a computer system that functions quickly for a user to interact with.

And that’s why I don’t really care about timings from a user perspective. They don’t care about their time anyway. You heard me. :) They care about the computer being fast enough, not about the time it takes for them to enter information, make a decision, or understand copy on a screen.

One stated aspect of usability is efficiency. Performance is part of that. I say just build systems that seem fast. Always build in progress meters like the spinning hour glass, or the venerable, “Loading…” People are willing to wait for a screen to paint if they feel the wait is worth while and that they are making progress overall in the task. If the load time is more than say, 3 seconds, toss in the progress meter. Sure, why not.

I have almost always found usability objectives, as exampled above, to be passé. All I ever care about is could the participant complete the task, and how many times did they mess up. Then I can look at what kept them from success under that measurement.

I will bet most people reading have never written a usability objective before. I envy you. I get why it is done. You want to design a system that allows you to measure it, thereby defining the level of quality. And everyone loves quality. So to measure something, you need a goal to meet in the first place. And to be on the up-and-up, that goal needs to be stated before you build.

First off, let me make you aware of my title: Ozymandias.

Secondly, a quick reminder: Sit down, shut up, and do your work.

Somebody hired you to do a job. Do that job. But knowing you as I know myself, you can’t help but do work that is considered by your organization to be “outside your role.” Do they get pissed when you do this? No? Hm, perhaps because you are good at what you do? Great. Go for it. Don’t like that you aren’t getting paid more for doing more work? Change that by either making a business case for more money, or stop doing more work.

Here’s what you own: the responsibility for delivering the work you promised to deliver. Now, in order to get that work done, more often than not, you need to deal with other people. Try being nice. If they show interest in what you do, let them tag along. Start key sentences with, “Hey, this might make your job easier…”

Want the world to take you more seriously? Start with the people with whom you work directly. If you add value, based on their subjective needs, then you are doing a great job.

Final point: There’s a big difference in how we all act, talk, and feel when we are in a room with “ux-related” people. In this arena, I encourage you to think big; bigger that you know is possible. Complain. Bitch. Navel gaze. Gaze at other people’s navels (with prior permission). Eat worms. Then, when you go back to your regular programming, sit down, shut up, and do your job.

The great thing about thinking big out-country is that there are many people coming into the “ux” field (and some who have been in a while) who still think it’s UCD or the highway. These people need to be attuned to the bigthink conversations. But when you are in-country, no one gives a shit what you do as long as it’s what they expect.

So you have a choice: do what they expect or change their expectations. Actually, many people will want to do both. Being Ozymandias, I have the luxury of always living in the “do what they expect” column.

And for my final curmudgeon-esque act for this post: Usability testing is boring. Boring, boring, boring.

Related: Too big & too small.

Because I am a mostly honest person, I’d like to make the following declaration:

I agree with everything that Jakob Nielsen says (today).

The last 200 years have driven centralization and changed the human experience in ways that conflict with evolution. The Internet will reestablish a more balanced, decentralized lifestyle.

I had a conversation at dayjob that revolved around the premise that software development is sadly chained to a manufacturing process approach both in design and development (as well as implementation and maintenance). We don’t have an answer for what should replace the manufacturing schema, just that we think it is a hindrance.

And, obviously we are not the only ones of late. (fyi’d by D. Keith)

The day it truly doesn’t matter where I do my work, as long as I get it done on time, is the day I will be really happy. The likelihood that I will still be employed when this happens is on this side of nada.

Some companies already do this, but overall it is the exception. We do it at Business Logs because we have to. Much like Yakob’s comment on virtual companies.

Virtual companies instead of big firms in centralized locations. Sorely needed improvements in collaboration software will let people better work together, even if they’re in different locations and work for different companies. Teams will come together for projects based on the required expertise, and then disband. Example: my own company is relatively small, but nonetheless has people in five U.S. locations and operates worldwide.

Though I would caveat his statement slightly (okay I don’t entirely agree with him, whew!): There is benefit in keeping small, persistent core teams that become very familiar with the product or service in question. Building teams based on expertise required is a good thing, but you shouldn’t rely upon it.

People who live with the product or service will come to know it and be able to anticipate needs and changes. The project teams built can come in with fresh eyes, so there’s benefit in that too. As usual, a middle path approach will work best for most companies.

Three articles, all written this week, that have an underlying theme of questioning the value of UCD and those who provide expertise in it.

The User-Centric Design Trap
[props] WebWord [/props]

UCD isn’t flawed. Rather, it was never intended to solve the complex motivational differences a person has when using a product, as opposed to voluntarily visiting a Web site. When was the last time you were on a Web site because you had to be?

Um, it’s called an intranet. I use it to get the work done in which the people who pay me are interested. The author does go on to state:

Software and pens are designed for consumers. They need these products, so UCD principles are warranted. Intranets, sites such as IRS.gov, even search engines function as tools, not persuasive systems. They benefit from UCD.

However, these “voluntary” systems he writes about are tools. Tools that support the goals of the user. “I want to buy X.”

If your goal is to create a profitable Web site that’s optimized to meet key performance indicator goals, then the UCD process, though well intentioned, falls short.

Attitudes like this continue to drive me crazy.

UCD is itself a tool. Only to be used when needed. And almost always to be used in conjunction (or better yet, integrated) with other methodologies. UCD doesn’t fall short in his example; it falls short in providing an holistic solution if used exclusively.

After linking to some of the articles referenced in the above article (which are all self-referential), my guess is that the author doesn’t believe that UCD ever falls short. I think this is just a poorly written premise for promoting a more holistic approach to design and development.

.:.

LL Spool J Kicks it Old School
[props] WebWord [/props]

The cost of frustration is one of our favorite techniques for demonstrating the value of our work. If we can pinpoint how frustrating the interfaces are and how that frustration is influencing the business, it becomes very easy to convince stakeholders that they need to change their designs.

We’ve found that, once we start focusing on the underlying cost of frustration figures, we end up with a very effective metric that we can use throughout the development process. It helps us identify which designs are most effective and gives us a tool to explain the benefits of good design.

Our close, personal friend Jared is at it again. In the attached article, he gives us a logical, minor treatise on why usability of a product matters, using amtrak.com as the poster child. Spool has two main audiences with this article: business, and designers & usabilityers. Who might benefit from this article, and what is missing? Since all good things and celebrity deaths come in three’s, let’s break designers & usabilityers down into three four (I forgot me!) major categories.

1. The newbie: This is the “my way or the highway” person. They wield UCD as a club and expect it to be used by everyone (as well as work for every situation which it doesn’t).
2. The practitioner: This is the person that asks better questions. They don’t ask, “Do you want to be successful?” They ask, “How successful do you want to be?” They understand that the companies that have enough money and/or care enough to hire them are already successful to some extent the company deems at least acceptable.
3. The guru: The penultimate position. These are people who have achieved fame and often fortune for really helping to turn around companies. They are the faces of usability and UCD. They are the reason we all have jobs. They also tend to write articles (and books) and think from a practitioner’s perspective. The guru is a leader, but not a visionary.
4. The sherpa: This person has transcended the guru stage. They know that enlightenment is a path walked, not a destination arrived. They are often confused with the practitioner level because they work for less money and have less fame than gurus. However, they also know that change is best when managed, not dictated. They have the vision necessary to transform industries, not just a single company.

Spool’s article is that of a guru writing as a practitioner. He makes a great point, but what he fails to realize is that Amtrak has no direct competition. Their prices are often similar to that of an airline ticket, yet their service takes n-times longer to deliver. In the article below, we see that one of the tenets of competition: either you become the low-cost leader, or you differentiate yourself from your competitors. The question that Spool asks Amtrak is, “How do we get more people buying from your website?” He should be asking, “How do we get more people to take the train?”

.:.

Pay 1$ for Design, Get 19$ in Change

Advertising specialists and marketing managers have long tried to appeal to the emotional element. But a growing number of companies are starting to feel that designers are more tuned in.

“With a marketing person, 90 percent of the time is spent trying to do everything to shape the buying decision,” said Earl Powell, director of the Design Management Institute, a forum for industrial designers and the businesses that use them. Designers are “more committed to the user experience. That experiential component has an emotional resonance: It sticks.”

Mmmm… IDEO…

We mulled many options, most of them revolved around using the Web in some fashion. As the core idea of Business Logs came together we needed something a bit more robust than the basic blog I started, so we moved to [plug] Basecamp [/plug] and within six weeks we were up and running. Over the past five months a lot of ideas were thrown around.

While some of the conversations over that time took place via email or IM, most everything is stored, categorized, and thankfully easily searchable on our development blog.

Last night I was looking through some of the ideas we had thrown out and thought, “There are some really good ideas here, but most of them suck.” I’m sorry, did I just admit to Mike, Paul and I having sucktacular ideas? Oh well, hope that doesn’t tarnish the reputation.

The truth is, and everyone knows it, that all companies have horrible ideas. We knew this going in and tried hard to think in terms of, “All ideas suck on some level, but they may not remain that way. It depends.” In fact, It Depends was the name of the blog that started all this.

Things change over time and what seemed like a bad idea back in February is now a really good idea. And I know that because it is stored on our blog, easy to find, and easy to periodically review. We started an informal idea analysis process, which I have drawn out in the following graphic:

Every idea goes through this process. Some ideas spend more time in one part of the process than others. Some ideas are pretty obvious to how bad they are, but still go through some analysis.

1. Business Drivers. These are all the things that make a business go. The things that need to be done, but also the things the business wants to do. When we get to the point of asking ourselves how something might play out, we move to the next step.

2. Task Analysis. I use this term because of my background in user-centered design. Task analysis is getting an understanding of what is currently being done to meet the business need (including what are the competitors doing) as well as mapping out how the current tasks need to change (the future state). If it still seems viable we head to design solutions.

3. Design Solutions. I am using design somewhat generically here. Basically the point is to come up with a handful of ideas on how the future state might work. This is often done by writing usage scenarios; narratives that walk through the new way of doing things. Then we pick a couple and prototype the solution.

4. Prototype. For Web-based ideas, this means mockups (wire frames). For more conceptual things we may just end with the usage scenarios. That?s part of the reason there is a back-and-forth line between Design Solutions and Prototype.

   There is also a back-and-forth line between Prototype and Task Analysis, because once you start working an idea through you start to see gaps in your earlier thinking. These are usually minimal changes, but it is always good to revisit your task analysis to make sure you are still on track with the original idea.

   There is also a line that goes back to the business drivers. I put that there because this is something we follow through with if we are working with a client. Taking the prototype back to the business partners and explaining how you got to that point is essential for buy in to move to the build stage (which is another map for another time).

5. Technical Constraints. This is always the fun one because it redefines what you are able to do with an idea. The back-and-forth line between Technical Constraints and Design Solutions usually plays out rather quickly. It is important to note however, that we try to not think about the constraints until we hit the design solution stage. A technical constraint now, may not be one in six months, but if you think about constraints too soon, you might give up on a good idea without really trying.

   A line also goes back to the business drivers, and this line is used much like the prototype line; when business partners are involved, it is important to relay the technical constraints. Partly because they may want to pay you to remove the constraints, and because they need to know as much information as possible to make a good decision.

Uh, Matthew, what about that parabolic weenie roaster?

This is why no idea sucks forever.

When I was in high school (aeons ago), one of the large mirrors in the weight room fell off the wall and smashed into pieces. Being the hippie school that it was (another story for another time) no one wanted the broken mirror to go to waste.

There were about four of us who had a great idea: use the mirror to create a parabolic weenie roaster. (I actually call them hot dogs, but Dean, the math teacher who helped us with, well, the math, called them weenies and the name stuck.)

We did everything necessary to build it, except actually building it. We did the math, drew the plans and never followed through. Part of the lack of follow-through was due to needing a power saw, but most of it was because we were lazy high-schoolers.

We had a lot of really cool ideas that never really went anywhere. Sometime we’d have a good idea that worked out and was even implemented. Those were rare occurrences, but I think that is the normal ratio: many ideas to few implementations.

We had our own, less refined method of idea analysis back then, and a lot of conversations that started, “Hey, what about…,” ended quickly with the following statement: “Sounds like a parabolic weenie roaster.” It’s a statement that gets thrown around still to this day between those of us who kept in contact from high school.

About a year ago, a friend from way back was thinking of developing some blog-like software, though much more to it. (Yes, even more than what is currently available or planned, so there. :P) Given all the other things he has going on right now it may or may not become a parabolic weenie roaster.

But the strange thing was that while I was talking to him, I was also looking through the latest (at the time) Discover magazine, and what did my eye behold? An actual, functional parabolic weenie roaster (sorta).

If only we had followed through on our parabolic weenie roaster that could have been us getting millions of dollars in research grants, being written up in Discover magazine and basking in the collective admiration of screaming science groupies (is there such a thing as a science groupie?).

Most of the ideas that Mike, Paul, and I have shared with each other will never see the light of day. But all of the ideas are worth sharing because at some point they may become viable, actionable, and implementable. And thanks to our internal blog, we won’t forget the ideas. We can revisit at any time and perhaps have the beginnings of our next Business Logs project.