Saturday, December 26, 2009

The Rule Of Ones

Working in one direction.

With a partner.

There is a basic rule: managers manage things and leaders lead people.

The world needs both. Which you need for a situation depends on that situation. Nothing is right everywhere all the time.

So, you think, that is very fine. Very fine indeed. Now how does that apply to me? I, for example, have a small business and don't need to worry about managing 1000 things or leading 1000 people. I am not in the thousands, just me and a few employees. The whole subject is academic, so what's for lunch?

Ah, lunch. Thank you for the reminder. We'll get to lunch as soon as we're done here, but first we must talk.

To start, let us divide the world another way, into Customer (that's you) and Developer (that's not you). Now, beyond this, let's also say that you need a piece of work done. Just for argument's sake let us say it's a web site.

Good. We are off to a fine start. Let's go another step. We have two parties and a piece of work. Now we need a relationship.

For a relationship we need the parties interacting. Luckily we have a good excuse, our web site. Our two parties will work to build one, and the working together will be the relationship.

To make a relationship work, really work, we need openness and honesty, and good faith. You don't get any more basic, or any more important. Besides this foundation you need a common goal, and responsibility.

Two parties, a project, working in tandem. Togetherness. Partnership. Check.

It's about adults cooperating, working alongside one another for a common goal. It's about going in one and the same direction. At the same time. Together. Even if you are working separately.

So here's the outline. First you agree to work together. Then you set the ground rules, and divide up responsibilities. After that you agree on a schedule (deliberate but flexible, with a set of milestones along the way). And then you get to work.

You work. And meet often. And adjust, and repeat until done.

And when you're done, you're finished.

This is all very nice, but there are those other details. The having two sides to this relationship. Two points of view. Two identities. Two separate worlds. And about leading and managing.

True, each party can be off working and temporarily out of touch. Not too far out of touch, but out. Customer and Developer each have specialties, and other things going on, and they tend to them. Capably.

Here's where flexibility helps because you can be both leader and the led, both manager and the managed, doing it all yourself, within your own sphere. You need (inside the relationship) to define and set your own goals, but you need minimal supervision. (None, in fact, except your contract.)

You must be good at self organizing, because you are it. You set the tone, prioritize, assign, and do. You are capable of building from scratch and seeing it through, and that's what you have to do.

You can work alone and not whine. You are fine with it because you have done it before and you know how. You have defined your own role. You have begun things and then finished them. You have initiative and an entrepreneurial spirit. You work hard.

You are smart.

Smart enough to listen and learn, and to share and inform. You adapt. You do things, which is what this is about.

Given these qualities, inside the relationship we've described here, you may have problems but not issues. Challenges but not disasters. Interesting times but not catastrophes. That's good.

In fact that's very good.

Let me know if you'd like to get together and cooperate on a project. You sound like my kind of folks. I think we could finish that web site just fine.


Wednesday, December 09, 2009

Breaking Up

Hints that you may need to try elsewhere.From SVN by 37Signals

It's a relationship!

If you ever get the impression that you can aim your credit card at someone, sit back, and have a fresh, shiny, new web site delivered, then you are likely to have your feelings hurt. And see your bank balance drop while you pull out your hair in frustration.

It doesn't happen that way.

Truth is, it's hard to get anything done, ever, let alone correctly, in either of two web development scenarios:
  1. You try to avoid problems by working alone, doing everything yourself. Good luck with that.
  2. You work with others, and you depend on them while they depend on you.
In other words, it's always hard. Do expect to work up a sweat. And while working with others, if you are very, very lucky, it's only half as easy as it ought to be. Usually things are much less easy, but there you are.

Say you don't have a web site but want one, or you have one but it needs refreshing. Well, basically, to make things happen you must shackle yourself to others for a while.

There are at least two sides to every web site deal, the customer side and the developer side. And of course things can go wrong on either side or in the middle. You don't want that but it happens. But you don't want it.

When things do go wrong you try to make them right, but there are times when it becomes clear that it is not going to work, so you have to dig out the key and unlock yourselves and go separate ways. You have to break up.

The blinding obviousness of the value equation.

Every business deal is an exchange. If you buy then you expect your money's worth. If you sell you expect to profit. It's a dynamic balance.

But sometimes the balancing part is off.

Maybe quality takes a vacation, or too many deadlines sail past, unnoticed. Maybe the work doesn't look all that bad if you squint, but simply does not match the requirements, and the worth isn't there.

On the other side, the developer might experience delayed payment, or none at all.

Time to break up.

Contractually speaking...

So let's say that isn't it. Maybe you want to renegotiate the contract on the fly. If so, there is something seriously off.

Let's say that no one here can be described as a devious schemer. Let's pretend. It happens, but let's say it's not happening to us.

You the customer have your developer trying to fudge. So think. If the developer needs to fudge the contract on you, is that OK? Nah. You don't want to play this game.

But you the developer, you are working in good faith, and competently, and then your customer clears his throat and what? You're being asked to also do this, that, and the other, for the same pay? Or else? You don't want that. You had a deal, you thought. That's what deals are, isn't it, deals?

Time to break up.

No adult supervision should be required.

You are an adult, and you spent a lot of time getting there. And it wasn't easy. Now that you are an actual adult you expect to deal with other adults in a grownup way. That's reasonable.

No whining and no temper tantrums is also reasonable. Another way to say it is that, at least for the duration of your development contract, you have a business partner, and that partner should act like it. No one on either side gets a free pass to be aggressive, abusive, or a bully.

Business isn't running with scissors. It isn't screaming. It isn't throwing anything. (Hope not.) So you shouldn't expect to either do it or be the target of it.

So if it's going on? Time to break up.

No, seriously, this is business. Isn't it?

There. You have none of these problems. Good. You shouldn't expect to. But we're not done yet. Because, after all, we're discussing how things go wrong.


You know how it is on one of those days? You can't seem to get started? It happens. There are valid reasons for it. Everyone has a day like that, every now and then. It happens.

But no one should be moping around on you. You especially should not be standing there, with the clock ticking, on time, ready to go, with your partner not there.

Meetings can be big time wasters. No need for them to be bad, really. But no matter. It's much worse to stand there alone, wasting time, and not have a meeting at all.

Expect people to be there, and on time, prepared. Expect focus. Expect deadlines to be hit precisely. Expect the results you pay for, and prompt payment when you deliver results. Expect that things work, including your business relationship.

Do not train yourself to accept tricks or excuses. Be good and expect the same. You are on a team, and the team has to work. If not, no ball goes through the hoop.

Customers, well, some of them have trouble committing to firm specifications, or pulling content together. Extracting (or creating) content (usually the written word) is hard. At least five times harder than you think. Maybe 10 times harder. Expect to see the calendar grow old while you pull it together for your developer.

And you, the developer, you shouldn't need to be reminded that there are milestones, or of how important getting it done can be. Like, for example, how a working prototype is better than a hand full of sketches you've already reviewed. Seriously.

So if your partner isn't serious, guess what?

Time to break up.

Sheep in the wolf pack.

Sometimes it gets sad.

Say you're working with someone you like, someone you know, someone you've worked with before, and you want your project to unfold like an elegant rose. You really, really want that. You do.

And instead you get a wilted dandelion.

If you're the customer, the one who is actually putting up cash, then no matter how nice you are you will find that you can't afford to work with someone whose skills are almost but not quite there. Can you?

Think about it. Your business needs are ignored, or you get a product that fits a developer's limited skill set but not your business, will that be fine then?

We'll let you mull that one over while we look in from the developer's side.

So, developer. You know what you are doing. You are a pro. You made the grade. You have the chops, and here is this person, who has never built a web site or done any design or programming, overriding your professional and technical decisions?

How does that feel? Good? Or not?

Time to break up.

Legal issues? What are those?

Cutting legal corners, misrepresenting anything, padding bills, bouncing checks, plagiarizing or ordering it to be done, well, no. Shouldn't happen. Eventually you can expect to be in court, if not prison.

Of course you wouldn't think of it. Not you! The other guy did it. But, keep in mind that if the other guy is doing it and you are letting it happen, um, well, you are doing it too, because that's your partner there.

Don't get caught doing it or paying for it to be done. Back away slowly. You are too close to someone you should not even know. You're better off without each other.

Time to break up.

Oh, hi.

Wow. No, none of those problems. So we're in the clear. Should be OK, right?

Although, now that you mention how good things are, there does seem to be one more thing.

Not really a "thing". Hard to say. Hard to describe. Sort of a nagging. A feeling somewhere in the background, like a vague soreness in the throat that never actually becomes anything. But it's there.

Maybe you have this feeling that you are simply not in the same universe as your colleague. Somehow you talk but don't understand each other, never connect. Like conversing by semaphore. The old you say tomato and I say rutabaga thing. Right, right.

And even when we manage a little communication, it, well, doesn't...something.

If you always seem to be getting confused, or feel drained after work sessions, well, then why do it? Get away. A change will be good for you.

Time to break up.


The oddest thing is, the earlier you do this the better. Both parties get to move on to a better relationship as early as possible, with the least loss of time, money, dignity, and all those other things.

It happens.

Don't look forward to it, but please don't let yourself be surprised by it. Stay awake, stay hopeful, but remember as well to stay alert. Every now and then it's time to break up.

Monday, November 16, 2009

Work Softly

Here's the premise: work is overrated.

You've heard statements like luck happens to those who are prepared for it, and Edison's "Genius is one percent inspiration and ninety-nine percent perspiration." Which means, if you think about it, "Why aren't you working, Fool?"

But working can be as much curse as blessing. Sure, there's no substitute to working something out, making it work, and working toward a common goal, and making that "ninety-nine percent perspiration" happen. But too much focus is as bad as too little, or worse.

Too much work makes you tired.

It makes you cranky.

It blinds you.

Ask yourself, if you haven't in a while, "Why am I doing this?" It isn't so you can do more of it, not if you call it work. No one, on his death bed, ever voiced regret at not having spent more hours at the office.

You do it because you have a goal. You want to be good and to have fun. Good first, and then fun too. You have to work to achieve a goal, but that goal isn't more of the same achieving, not more work. It's something else, and sometimes working gets in the way.

A few years back someone came up with the idea that we each have two minds, based on differences in how the two halves of the human brain work. One half is good at linear thinking and breaking problems down into bits and then cracking each one of those at a time. The other half is imaginative, less predictable, more artistic, and takes big bites of things.

See, there's one thing though. We need both halves to make a whole. You don't want to be all giggly and unpredictable and surprising all the time, and you don't want to keep your tie cinched up tight all the time either. But a lot of people a lot of the time think that somehow just being extra serious and extra focused and extra grim will be extra successful.

It won't. It will be extra grim.

Which is OK if your name is Grinch.

But maybe it isn't.


Why are you doing this, ultimately?

You know, money isn't at the top of the list. In survey after survey people rank money up there somewhere but not at the top. People want meaning and a sense of community, and of accomplishment and a feeling of being valuable more than they want money. In other words, people want to do good and have fun.

Which is where we are at the moment.

If you want to do something excellent, something valuable, something worthwhile, something good, something that pays off, you have to be kind to yourself and to others, and you have to stay open. You can't do that simply by working harder. Doesn't work, so to speak.

Someone I worked with used to say "Don't work harder, work smarter." That helps. Smart goes a long way. It supplements hard work, and in a lot of cases it replaces it, but in a sense it's more of the same. Being really clever about investing less work in something and getting the same result is pretty much hard work by another name. And also involves less hard work, which is good.

But mostly it's a focused drive toward a predetermined goal along an chosen route. Sometimes you have to relax, and sometimes you have to get goofy too.

Break things up. Leave something to chance. Invite the unexpected.

This is a recipe for disaster.

Disaster can be good for you.

Sometimes disaster is the best thing that can happen to you, and it doesn't have to be bad to be good.

Here's the rule: stay open. You can rephrase this as being humble. That is excellent.

Go somewhere unusual. Talk to someone new. See a movie picked at random. Stop for lunch at the first place you come to. Sleep late. Stay up late. Go to work at two in the morning. Get drunk. Remember your dreams. Pray for a disaster.

Graphic design isn't easy for me. I'm working alone, on a personal project, so I have to do it all. I spent days on design. First I sketched things out on paper. I did a few, and decided what direction I was headed, then did some wireframes on the computer, in black and white and shades of gray. Thought I had it. Was sure of it. All was going well. The only thing I needed was to do more work. Just keep my head down and plug at it.

So the next thing was choosing colors, which is hard for me because I'm "color blind". Sort of. Not exactly, but enough to make things harder. But I got a color scheme.

So, on to creating full page-designs with color. I worked and worked. It was slow. One or two a day. Trudge, trudge.

Getting toward the end, almost done, I suddenly did something differently. Changed the design. Put colors in different places. Created a mess. Had a disaster. Found a different way to do it.


It's better.

Now I have to go back and redo everything I did during the past week and a half. All because I changed one or two little things, saw it all fall over, and decided I'd been going the wrong way after all.

Call it inspiration.

When this happens to you, pay attention. This is the crack between worlds. This is when things really happen. This is your free introductory offer. This is your one percent. Your inspiration.

You still have to do the 99 percent perspiration, but it's good for your skin anyway, so buck up and start grinning, even if it hurts for a while. You have been blessed. Wait for that smile. It will come.

Randomness is good. Inspiration is good. Being good is good.

Partly because it isn't work, but partly because it balances you. You can't live that well with half a brain, and you know what they call someone with half a mind, so party on. You have just been made whole.

The point, the whole point, and nothing but the point is that there is more to life and love and work than one thing. More than the grind. Grinding isn't the whole story, it's only the grinding.

Part of it is having the right idea. Part is working on the right problem. Part is locating the right market, the right customers. Part is looking for where you can do good. And part of it is finding out how you can have fun.

And, in case you were wondering, yes. This works for web development too.

Working hard is overrated
The first-to-market myth

Feed your head: "Laura Buxton, an English girl just shy of ten years old, didn't realize the strange course her life would take after her red balloon was swept away into the sky. It drifted south over England, bearing a small label that said, 'Please send back to Laura Buxton.' What happened next is something you just couldn't make up - well, you could, but you'd be accused of being absolutely, completely, appallingly unrealistic."
Radiolab mp3 file

Wednesday, October 28, 2009

Information Architecture, part 5

Defining Success.

Success in designing and building a web site depends on communication and collaboration among team members. Everyone needs to understand the goals, perspectives, and approaches of the other team members. And these need to be decided on up front.

Communication is a special challenge because of the intangible nature of this work. The information architect must identify goals and content, keep them in mind, keep them visible, and keep everyone on track.

The biggest cause of failing projects is not defining the problem to solve.

If you don't know what your goal is you can't tell if you've reached it. And even a well-defined goal can be the wrong one, so it's important to question everything every step of the way.

Typical Problems and their Causes.

Software development of all kinds suffers from the same kinds of problems. You can lump all these together under poor planning.

It doesn't really matter who is managing. If a project isn't thought out then it can't be run well. If a project is not run well then it can't succeed. No amount of hard work can fix things.

Software development is one of the newest and hardest kinds of creative work, and not all of the rules have been worked out yet. This goes double for web sites, so it pays to be cautious.

Problems come from not knowing the rules, and from deciding to crack the whip louder, hoping that everyone is suddenly working faster and feeling happier. Well, it will force people into line, temporarily, out of fear, but that won't help anything. At all.

So, check these out:
  • Have clear, documented goals.
  • Know your requirements.
  • Objectively assess.
  • Attack risks.
  • Devote resources to testing.
Want to fail? Start without clear, well documented goals.

Here's the number one rule: If it isn't written down then it doesn't exist.

And if you don't think that's true then try to prove it. You can say one thing, then have someone disagree, and then where are you? If there's no proof, there's no proof, period.

Running on hearsay doesn't cut it anywhere, and surely not in business. Writing down your thoughts and passing them around is often enough to uncover huge gaps in your understanding. If not today, then tomorrow morning when everyone is taking a fresh look. If warts are there to be seen, someone will see them.

Ad hoc requirements management is another big issue. Same lack of planning.

Don't expect to shoot from the hip and hit your target. You have to know what your project requires and so does everyone else. Flying without a plan is at best a guess, which is a huge problem. Everyone has to work together with a clear mission or else you all get confused.

With no plans and no documentation you get inconsistent requirements, mismatches between requirements and design, and more mismatches between design and implementation. More points of failure. You need fewer ways to fail, not more.

If you keep getting it wrong you'll have even more plagues and pestilences. Subjective assessment of project status, for example, rather than knowing for sure. It's a lot like having a hunch about your checking account balance, expecting everything to be just fine because you want it to.

If you start confused you probably haven't assessed the risks to your project. Ignore risk and it will blindside you. Not attacking risk means it is free to attack you. At best you end up with a brittle architecture. One that is too complex, too big, too cumbersome, too weird.

No matter who you have on testing (you have a dedicated testing staff, right?), your testing will be poor. Even if it's automated (you have it automated, right?).

On top of all this, if you do manage to get something limping along you will then propagate changes in an uncontrolled way, so you be piling new messes onto the old ones. A big, tangled mega-mess is what you'll get. One that can't be either fixed or added to any more. And then what?

Best Practices.

There are some best practices though. As with a lot of things, they may be hard from time to time, but they're pretty simple.
  • Develop iteratively.
  • Manage requirements.
  • Use patterns and templates.
  • Visually model systems.
  • Control changes.
  • Continuously verify.
Develop iteratively. Don't ever, ever try to do the whole job in one pass. It's way too easy to miss a turn and end up in the wrong country by keeping your head down. This is not a good experience.

Manage requirements. Sounds simple. What is it? It means that you have to keep learning what you need as you go along. It's like having a grocery list and throwing a few more things into the cart when you realize you left them off the list.

Use patterns and templates. Know enough about what's been done before, and how it's been done, so you can work with a proven solution and more or less fill in the blanks as you go along.

Visually model systems. A few sketches can do it. You can sometimes answer a question with a picture in less time than it takes to ask. If it's the right picture.

Control changes. Developing iteratively gives you flexibility to add and remove things, but knowing your requirements keeps you from getting carried away. You have to know which road to be on, and then stay on it.

So you also continuously verify progress, continuously reassess your goals, and continuously verify quality. In other words don't assume that going through the motions is enough. You keep looking around, checking the compass, making sure all the wheels are still attached. Quit paying attention at your peril.

Get Used to an Iterative Approach.

Every project, and every step of every project has a beginning, a middle, and an end. No one says you can't pass by them several times before pulling into the garage.

Begin, then plan. Gather requirements. Manage the environment. Analyze, and then design. Implement, and then deploy. Test everything, every step of way, including requirements, analysis, and design, not just finished work. Test yourself. Test your customers. Everything.


Then repeat until done.

The more you do something the better you get. The more you do something the more familiar it gets. The more familiar things get the easier they are to understand. And the more likely it is that you find the warts and bugs and scabs when you can still do something about them.

Iterate gladly. It's good for you.

Iterate because iteration keeps you from failing, and from losing your job. Or your business.

Iterate because it's faster, because you never have to stop, and back up, and undo a whole bunch of work, and then do it all over while hoping for the best, while sweating blood.

Iterate because it works. If somewhere you make the wrong assumption, you won't be going too far before pausing at the next checkpoint.

This is creative work, not manufacturing, not floor sweeping. It's all too easy to miss critical factors. Human factors. Business factors. Technical factors. You name it. Especially when moving from the familiar into the unfamiliar. Take small steps and watch for tigers in the trees.

This iterative approach will help you. The single big leap (the traditional "waterfall" approach) will bite you. Hard. Remember, the point at which you know the most is at the end of the project, not up front. So plan on finishing small stages several times, and not on laying it all on the line once only.

Some Wrong Assumptions in the Waterfall Approach.

Assumption 1: Requirements are frozen. Nope.


Users, visitors, and business conditions change. The most fundamental business problems change over time, and sometimes that time is a few days or a couple of weeks.

Assumption 2: Technology never changes. No, seriously. It does.

Assumption 3: Markets don't change. What did we just say about business conditions?

Assumption 4: The level of detail in your requirements is always perfect. If you assume that they're right, and chisel them into stone, and only find out way late that you are way wrong, well, good luck there.

Assumption 5: After you've gone over the cliff is a good time to change your plans. How are those frozen requirements working for you then? Still OK?

Assumption 6: The design is right on paper, so it's right, period, isn't it? Heh.

Assumption 7: Risks can be put off or ignored. In other words, if you assume that you can leave the hard stuff until later, or maybe sort of ignore it and it will go away on its own, well...

Assumption 8: Time scales can be expanded with no problems. Sure. Just expanded and expanded and expanded, and then a miracle happens. Works every time.

Assumption 9: Reams of paper documents on shelves are really valuable. This is fine if you are producing documents only to decorate shelves. Documents like to breathe, and move around, and interact with people, so why not use a wiki? Or have quick, informal meetings every couple of hours or so?

Assumption 10: You'll get the first version completed, something that works well enough for now, and then when you have time and money and staff you'll go back and do it right. You'll add all those things that should have been there at the start. If you're still around. If anyone can remember what it was that somebody mentioned once upon a time.

If you ever get that time and money and can recover the creativity for it. Or maybe not. If the company is no longer business.

On the other hand.

With an iterative approach:
  • You mitigate risks earlier on. Nothing like swatting that mosquito before it bites.
  • Change becomes manageable. Because there is only a tiny bit of change from one iteration to the next.
  • You get more reuse because you pass by things more often and start to see where you can use one piece of code or one template in half a dozen places instead of inventing it over and over again. Or you invent a pattern to apply in similar cases.
  • Everyone learns along the way, because you have a team approach and the whole team watches the scenery roll by again and again. And so quality gets better. Inevitably.
How about that? Success.


Wednesday, August 26, 2009

Information Architecture, part 4

Artifacts and Processes.

-- Artifacts --

Several kinds of artifacts show up during the development process.
Input Artifacts are:
  • mission statements
  • organization charts
  • records from previous projects
  • vision documents
  • analysis of the competition
  • documented business models
  • documented visitor personas
Output Artifacts are diagrams, documents, and different prototypes.
1 - Diagrams
  • use case
  • navigation
  • interaction
  • sequence
  • site map
2 - Documents
  • use case scenarios
  • data and search dictionaries
  • general design notes
  • technical specifications
  • data entities
  • processes
  • wikis or other intranet sites
  • stakeholder interviews
3 - Prototypes
  • page layouts
  • wireframes
  • graphic mockups
  • navigation maps
Input/Output Artifacts. Several types of items may both go into the process and also emerge from it. They might be modified along the way as well. Some are:
  • photographic and other images
  • data
  • logos
  • business color schemes
  • sound and audio files
  • marketing documents
  • technical and help documents
-- Processes --

There are many processes involved in information architecture. Just because there are many doesn't mean that anyone has to get hogtied by details. Processes exist not to stymie you but to help. Use the processes that are appropriate, and only as much of them as you need. But do plan on being thorough. These were developed to help, and they will. But only if they are used, and used well.

1 - A process to define functional requirements.

Defining functional requirements determines what content your site needs and how to access it. Content can be static, dynamic, or transactional. 1 - Static content
  • copyright notices
  • privacy statements
  • other boilerplate
2 - Dynamic content is anything that changes frequently, like
  • a news or new features page
  • rotating images
  • customer feedback in a forum
3 - Transactions
  • logon pages
  • signup pages (for newsletters or other services, including shopping pages)

2 - A process to define a site structure.

Do this by keeping your site's purpose in mind. Brainstorm. Gather people and generate ideas, then review and evaluate. Don't discourage anything while brainstorming. Anything. Instead get all ideas out in the open and filter them later. It's easy to kill a good idea but hard to find one.

Get the basic items knocked out, then repeat. Keep repeating and refining until done.

3 - A process to develop an architectural blueprint.

Developing your site's structure results in an architectural blueprint. This blueprint helps everything else to fall into place and makes it easy to define navigation.

Structural and navigation plans together make page layout and template design easier. One mistake that many companies are tempted to make is to copy the company's org chart as a design, but this is not good site design. Customers don't care about corporate structure. In fact, a customer could care less who reports to whom, or how the business units are managed. If they did, you would know about it. Customers have their own needs, which are not reflected in the way the business is organized.

Start with a general overview and then get into the details.

Describe the larger sections of your site and and the groups of pages that define them. Then move to individual pages, and then to the elements that comprise them.

Define the links that connect the parts of your site to each other, and the links that lead off site.

Document everything. Keep the overall goals front and center.

4 - A process to integrate metaphors.

Fold in metaphors. There are two kinds.
  • Functional metaphors relate tasks on a site to other common tasks that may exist in other environments. Think of "cut," "copy," and "paste". Those are functional metaphors. You know them. They can apply to many different things in many different environments. Similarly, you can use other metaphors to design, create, and maintain your site.
  • Visual metaphors are graphic elements that are common and familiar. Think of "start," "stop," and "pause" icons on an audio player or video player. Use similar ideas for your site.

5 - A process to develop the visuals.

You have to create a visual design. Visual design creates a unique sense of place. It defines landmarks.

A visitor creates a mental map of your site while exploring the sites visual design and structure. Graphic designers, art directors, creative directors, and developers collaborate to create this.

Design sketches establish a look and feel. They are often done concurrently with other parts of the development process.

One way to overlay a site's structure onto a visual design is by using a grid pattern. This is a well known technique in graphic design, and ensures that elements are consistently aligned. While doing this, define the site's structure and organization all the way down to the page level.

You can use sketches to establish a general look and feel, and then move into page mockups by combining the sketches with grids, finally using the page mockups as prototypes for the finished pages.

Grids are really handy for defining overall layout, and help to block out global and local navigation as well.

To use grids, first create a rectangle representing a page, then block out the major design elements on that page (content, branding, advertising and sponsorship, navigation, page titles, header graphics, footers). Then refine. Iterate as often as needed.

6 - A process to create mockup.

Page mockups represent your site at a nearly finished stage. Integrate design sketches with layout grids to produce the mockups.

Mockups come in when the development team is almost ready to start programming and they establish the basis for more refined prototypes (or the basis for building the actual site, if it isn't too big).

Keep the design documents up to date. The design document's visual design section records what layout grids were selected and why. It includes diagrams and illustrations of page mock-ups. You can think of these as static prototypes.

7 - A process to enhance understanding.

Understand everything.

Essential areas to understand are:
  • business objectives and constraints
  • site content
  • visitor requirements
To understand business issues, study existing documentation, previous research, previous projects, and vision documents. Don't' forget to include mission statements and organization charts.

Remember to interview stakeholders for insight into the business context, and keep digging to uncover issues that might not be obvious to everyone.

Create inventories of content to hone your understanding of what the content is. Content inventories are collections of both content and potential content. It's important to identify it, to know where it is and who owns it, to be aware of the relationships between pieces of content, and how those pieces relate to the project.

8 - A process to define Goals.

Clearly define your site's goals. This ensures that everyone on the team moves in the right direction. Keep basic questions in mind:
  • the purpose of the organization
  • its short term and long term goals
  • the short term and long term goals of the site
  • the site's intended audience
  • what the site's draw is supposed to be

Then rank the goals, document them, and publish them for all team members to see.

9 - A process to understand visitors.

Don't forget to understand your visitors. They are what your web site is all about. To understand visitors you first have to define who you think your site's audience might be. Ask questions like who will be using the site and why. Use narratives and scenarios to visualize your proposed visitors and what they might do at your site. Then rank potential audiences by importance (and plan to deal with the most important ones first).

Use your scenarios. Visualize the site's operation, and its users. Using scenarios is a great way to validate the design. To create scenarios, interview typical visitors, concentrating on those who represent the most valuable audience. At the end of development, your actual site should match the scenarios.

10 - A process to evaluate the competition.

Dissect your competition through competitor analysis. How? Study the strengths and weaknesses of actual and potential competition and evaluate your site in that light. Then create a list of ways to better what your competition is doing. Download time, page size, attractiveness of layout, usability, and look and feel are all important, as well as specific products or services. If you have an existing site, then evaluate that too. Publish the results for everyone on the team to see.

11 - A process to tidy up loose ends.

Identify content and functional requirements. If you know the content then you know what your site will contain. If you know the functional requirements then you know what it has to do.

After listing the content and functional requirements, have the development team reach a consensus about them.

Create an inventory of content. Content types (as noted earlier) can be static, dynamic, functional, or transactional. Roll individual lists of content types from various team members into a master list, which will be your "content inventory."

Review the requirements. Determine the feasibility of each functional requirement. Ask if the technology and skills to meet them are available. How about the time and money to buy or build the needed functionality?

Rank your requirements. You can't fulfill all of them, at least not at first. Concentrate on the most ones important first, even if they're the hardest. Putting off the hard things until last ensures failure.


Wednesday, August 12, 2009

Information Architecture, part 3

Roles in information architecture.

Information architecture needs people filling many roles. On a small project one person may take on several, or all of the following.

Information architect.

This person defines your site's structure, its content, and its functions. The architect does this with an eye to both business and visitor needs. But information architecture is an art. It's abstract. It is hard to communicate sometimes. Because of this the architect has to work well with others, and has to be good at communicating complex ideas.

Every information architect should be a generalist, but especially needs decent skills in visualizing, defining, and organizing information.

The architect needs to think like an outsider (remaining sensitive to visitor needs) while being an insider (who understands the business and its mission).

The architect needs to have empathy, and should be a quick study.

Creating a site that mirrors a product brochure is a mistake. Creating a site that mirrors an annual report is a mistake. A decent information architect can help avoid mistakes.

Remember that the average new visitor gives a web site only four seconds. Four seconds to get the message across. Four seconds to tell a compelling story. And then that person can simply click away, never to return.

So the information architect has a role to play. A crucial one, in making sure that each web site can entice, hold, entertain, inform, and repay visitors for time spent at a web site.

User interface designer.

Works to make a user's interaction with a site as efficient and pleasant as possible. Good interface design helps usability without drawing attention to itself. It is often overlooked or assigned to someone as a second role, but user interface design is critical, and should not be handed off to someone as an afterthought. Especially not to a programmer.

Usability engineer.

Is an expert at testing and evaluating systems. Concentrates on measuring system performance from a human angle.

Marketing experts.

Understand target audiences and how to communicate with them. Marketing expertise ensures that the business message is presented properly and not buried in jargon, or lost.

One drawback: marketers are geared toward selling, but helping users is extremely important too, sale or no. Make a good impression, provide some value at no charge, and you may have a customer. Word of mouth can make or break a business, and rarely shows up on sales reports.


Programmers, database designers, operating system and network specialists and others have the technical skills for modeling content and creating working databases and web pages. They usually are not trained in user-centered approaches to designing information systems. And even if they are, they don't have the time to do it justice, except on very small projects. These folks deal in nuts and bolts. Important things. Very important things, but done behind the scenes.

Graphic designer.

This is a person who oversees the layout of site-wide visual elements and creates a site's overall visual identity.

Graphic artist.

Creates specific images, logos, and pieces of artwork that contribute to the larger visual design.

Copy writer.

Copy writers focus on language. They write, proofread, edit copy, and massage content so a site has a consistent voice.

Project manager.

This is the person who keeps things on schedule and within budget. This person is a facilitator and a communicator, not a dictator. The project manager is a negotiator among team members and stakeholders, a go-between, and must be dedicated to maintaining a comfortable and productive working environment.

The project manager's job is to juggle the needs of staff, the needs of the schedule, and the tasks to be done. The project manager's job is not to give orders but to take them, to ensure that everyone can work at full potential.

And finally...

Back to the information architect for a moment. This person needs to know at least a little about each one of the other specialties as well. The architect's work affects each part of the process, and all team members. The architect is the keeper of the big picture, but has to stay flexible enough (and creative enough) to come up with new ideas on the fly, as required.

Wednesday, August 05, 2009

Information Architecture, part 2

The consumer perspective.

There is a consumer or site visitor perspective. It has two aspects, reflecting who comes to the site.
  • Targeted searchers. These people know exactly what they want. They know that what they want exists and they know what it's called. They want to find it, take care of business, and then leave. As painlessly as possible.
  • Casual browsers. These are people who don't know exactly what they're after. They come by with a vague idea, or maybe by accident. They explore. They bump into things, and learn about products or services that maybe they'd never even heard of before. Do your site right and they'll come back again.
Many users switch between targeted searching and casual browsing. A good architecture supports both.

Great graphics and reliable technology contribute to making happy visitors, but they aren't enough by themselves. Any site must actually deliver value.

The producer perspective.

This is the business view. And as you would expect it is a little different from the consumer perspective.

A well-designed architecture, one that scales, can prevent an expensive and early do-over. It does this because it keeps the big picture front and center. This is important for a business.

Too many site builders dive in head first without planning. You can get a site that is a confusing jumble of options, a site that tries to serve several different audiences while failing at everything. These things happen when you lose perspective, or never have it to start with.

Committees in large organizations with conflicted goals and messy politics can design sites that look the part. Competing visions and uncertain deadlines prevent issues from getting resolved. Sites built this way can't work well, even after huge amounts of time and money. Adding more people to a project only makes it slower and more likely to fail.

Problems in information architecture don't go away. No problem does. Resolve problems before a site goes live or those problems will get dumped onto the internet. Onto your site's visitors.

A frustrated customer will leave after a bad experience. A potential customer will never become a real one.

And another thing.

Without a clear information architecture as a guide the site's maintainers won't know which end should be up. They won't know where to put new features or how to update the existing ones.

Instead they will try their best but can end up adding to the mess. No matter how good they are and how hard they try there is no substitute for getting it right the first time.

Monday, July 27, 2009

How I Mistook My Web Site For A Club.

Right, wrong, the web, and you.

The old rule of thumb is that there is one way to get something right, and many ways to make a mess.

This is still true. False, but true.

Say you have a business, and you want a web site for it. Let's not think about the exact, precise focus of that web site. You may be selling potatoes or psychiatry, or sharing your feelings. It doesn't matter right now.

The point is that you want:
  • To do something, and
  • A web site to make it happen.
OK, fine. So what's MY point?

Fair question. My point is that, even if you want to do one narrow, focused, extremely specialized thing, there is one right way and a lot of wrong ways. And also a lot of right ways.

Confused? Try this.
  • Time matters. Today is different than five years ago. Next year will be different than today. The right answer for now is not the right answer for yesterday, or tomorrow.

  • Location matters. Asia is not South America. Florida is not Montana. Spokane is not Seattle. Main Street is not Avenue E. Different languages, different cultures, and different clientele demand different right answers, nicht wahr?

  • Market matters. Markets vary by time and location, but also by economic class, by industry, by tribe, by level of coolness, and in other ways. Your market may be a moving target, or you may be. You may be a follower or a leader, but either way you need to work to hit the target.

  • Fill in the blank. We don't want to go on all day, so you try a few. You know your business and all is facets, so you can continue this game on your own.

The Big Secret To Success.

OK, given all of the above, this isn't a free-for-all. There are still some underlying rules.

There is not one, unchanging way to produce exactly one right web site. If there was, we'd see only one web site, and it would be repeated endlessly. In case you didn't notice, the world hasn't done that.

However, there are some guidelines to follow. Think of a big highway.

A big highway has many lanes. You can get on the highway from many places. You can get off at many places. And in between you can drive as far as you want. There is no one right trip. You can start many ways and end many ways, and go many places, but despite that you still have to stay on the road. And follow the rules.

It's the same with web development. You have to pay attention to some things, but within broad guidelines you can go with the flow. Here are some things to keep in mind.
  1. Architect adeptly.
  2. Never neglect navigation.
  3. Deliberately design well.
  4. Get graphic, artfully.
  5. Don't copy, write!
  6. Keep content coherent.

1 - Architect adeptly.

Architecture is the overall design of your web site. Maybe your house is one big room, but probably not. Neither is your place of business, and your web site shouldn't be either.

Unless one big room is exactly what you need, and it could be. It's fine for some sites. But that depends on the business and what you need to do.

On the other hand, neither your house nor business have hundreds of tiny rooms. Probably. Your web site shouldn't either. Unless it needs to, unless you have a really good reason for it, and this all uniquely fits your business.

Site architecture should:
  • Reflect the business needs.
  • Support the customer needs.
  • Fit the information you're displaying.
  • Be understandable.
  • Be as simple as possible.

2 - Never neglect navigation.

Navigation depends on architecture, sort of. In fact, the word "navigation" implies failure, but it's the word people use, so let's stick with it.

Whoa, failure?

If you think about it, you shouldn't need "navigation" to get around. Do you need a map to get around your house (we're picking on your house again), or your business? Even your city?

In a city, even it's a big one, you find out pretty quickly where you need to go, how to get there, and after that it's "intuitive". You do not need a navigator or any maps at all.

Web sites are a little different, because cities, in a way, are all similar. A city isn't an information system, but a web site is, and each web site has a different purpose, and so needs thought.

And web sites change frequently.

For good navigation:
  • Keep the site as simple as possible.
  • Let visitors know where they are.
  • Let visitors know where they can go.
  • Show visitors how to get there.
  • Keep travel times short.

3 - Deliberately design well.

If you feel fine working out of a cardboard box, then we're done. If you pick your clothes at random out of a freebie bin on the street corner, then we're done. If you don't care, then we have nothing to discuss.

For clothing, you want something clean, comfortable, convenient, protective. And not scary. Something appropriate to the situation. Appropriate to you and to your audience.

For web sites too. It doesn't happen by chance. You need design.

What kind of design? Graphic design.

We just covered the big architecture and the navigational floor plan, so now we're talking paint, lighting, carpeting and things like that. You want a "look".

For each dimension of your web site you need a pro. For this one too.

You want the right:
  • Colors.
  • Sizes and shapes.
  • Visual weights.
  • Typography.
  • Emotional effects.
This is all vague touchy-feely stuff, easily avoided and ignored, until you see what a good graphic designer can do. Or a bad one. Then you understand.

This is as important as the name of your business. As important as your phone number. As relevant and fundamental as a safe, secure shopping cart.

Check out sites of big name, influential companies and you'll catch on.

4 - Get graphic, artfully.

Do you have a company logo? If not, then get one.

When you find an artist who can do one the right way you've probably found a good artist for the rest of your site.

But maybe you need mostly photographs. OK, fine. You need a photographer too. But this is still art.

A graphic designer deals with big, sweeping issues, like color. A graphic artist, however, deals with smaller, more specific elements like logos, drawings, diagrams, icons and so on.

You might not need a lot of art but be sure that what you have is good. Get someone who knows what they're doing. No finger painters.

You might want an artist to:
  • Scale your logo up or down for use as a recurring element.
  • Work a familiar and respected company image into several formats.
  • Create a unique set of icons or other symbols.
  • Convert photographs into posterized images or line drawings.
  • Develop original works of art that are distinct to your brand.

5 - Don't copy, write!

Words. Gotta have 'em.

You know they're good, but are you? Sure you can read and write, but can you write well enough to make a living at it? Think about that.

If you aren't really that good, then don't kid yourself. Use someone who can make you look like a winner, not a joke. Bad copy writing tags you as a loser. You can do gooder than that, betcha.

A copywriter can:
  • Create company slogans.
  • Write newsletters.
  • Develop ads.
  • Help optimize for search engines.
  • Keep all your text in sync.
  • Generate press releases.
  • Produce smooth, crisp, meaningful content.
  • Turn visitors into customers.
  • Make your hair stand on end.

6 - Keep content coherent.

So then, does this add up to something?

Well, that's up to you. The architecture of your site, the navigation, the look, the feel, the art, the words -- they're all team members. If they work together, you get effective content.

Content? Is that it? And it means what?

It means the point, as in what the point is. It's your message. It may even be your product.
  • If you're a blogger, your content is your words, and what they mean.
  • If you're a photographer, it's your images.
  • If you sell products, your content is your catalog.
  • If you sell services, your content is a demonstration of your smarts.
  • And always, content projects your credentials and reputation.
So, it varies.

Remember back to the beginning, where we said there was only one right way, and also several right ways? Well, this is it. Content is the milk in the glass, the steak that produces the sizzle, the story of the story.

If you are captured by a web site, it has good content. If you get the picture, understand the story, move in the groove, it's because of content.

It's not the instruments, or the musicians, or the dance floor. It's the dance. Get people dancing with you and you've got it made.

What this all means.

So we've trudged through all these ideas and sketched them out. You have a good idea of the different web site dimensions, but just to be clear about all this, we have to repeat that this all serves two purposes:
  • Serving your customers, and
  • By serving your customers, serving your business.
That's what it's all about. You don't go through this process if you don't care. If you don't care then you don't care, and there is no point to any of this.

But if you do have a business, and you want it to thrive and grow, then you pretty well need a web site. And if you have a web site it should be a good one.

A good web site:
  • Is focused.
  • Is easy to use.
  • Is pleasant to use.
  • Is simple.
  • Serves the business.
  • Serves customers.
  • Is kind of fun all by itself.
Get a good web site and you're off to a running start. But don't forget to keep thinking about it, because no one solution is forever.

And one more thing.

So why is this titled "How I mistook my web site for a club"?

Because, if you want to get things wrong then ignore all of the above. Pretend that the web is a way to trick people into giving you money. Only a way to beat them over the head.

Pretend that no one will ever know. That no one will ever share their impressions electronically, instantaneously, worldwide, permanently.

Pretend that it's all about you, only about you, what you want, what you need. Pretend that the world is there to serve you, and not the other way around. Fine.

It's only your business that's depending on it.

Your call.

Quick references at Wikipedia:
Information architecture
Web design
Graphic design
Copy writing
Web content

Friday, July 03, 2009

But Not The Kitchen Sink

I once worked with a guy. A nice guy. A smart one.

He was tall, and looked good. He was healthy. He made more money than I did, had a fancier job title.

He once tried to talk me into doing his work for him, but my one good brain cell caught on, and headed him off at the pass.

He normally didn't do that. Only that once. We were friends. But he was really stupid too.

At least I thought so, because of how he tried to have fun.

He had a wife, and they had two children. This isn't the dumb part.

They owned a house (also not dumb).

They had bought a timeshare condo at Cabo San Lucas. That's at the tip of the Baja peninsula in Mexico. (I hear distant sirens.)

This entitled them to two weeks a year. (The sirens are getting louder, approaching rapidly.)

So since they had a timeshare condo, this was where they had to take vacations. (Yikes, an ambulance is going to run over us!)

None of this mattered to me outside of its recreational value though.

When I hear this sort of thing I feel lucky not to be involved. But it makes entertaining talk at the cubicle farm.

Some parts of the story made my hair stand on end. The parts about how they packed and what they took. Golf clubs, swim fins, toys, a stereo system, a video gaming system, bicycles, a raft, and enough other things to squeeze all the remaining air out of their car.

Or maybe it was a van. I forget. Again, not my problem but I had to wonder.

What I had to wonder about was how anyone could have fun buried in clutter.

They didn't, so much, I guess. Vacation time was work.

There was lots of organizing, running around, packing, unpacking, and yelling (as it was told to me). Many things got moved from here to there, and then from there to here, and most of those things were not used at all (but were there, just in case).

After two weeks everyone was back home, resting up. Dreading the unpacking.

Unfortunately most software projects are like that. Except less organized, and much less fun, and much more expensive.

Here is the typical process, compared to a vacation from hell.

Vacation Software project
Buy the timeshare contract. Start locked in to a solution before you know what the problem is.
Call the family together. Hire staff (without knowing exactly what they'll do).
Reserve vacation time. Create a schedule composed of wild guesses butted up against iron clad delivery dates.
Fill the car with everything you own. Buy, lease, or steal tools. Any and all possible tools, especially the wrong ones.
Drive like crazy for days. Work, work, work, and hope you get somewhere.
Once there, do stuff, but don't have fun. Work, undo, rework, and hope you get something done, somehow.
Fight a lot. Form factions. Work at cross purposes. Argue, gossip, fight, swear.
Drive home, frazzled. Fall into your own bed, at last. Declare victory. Deny reality. Pretend not to notice the warts, or the fact that this toad has horns.
Go back to work. Spend evenings falling asleep in front of the TV. Nap on weekends to recover. Assign regular staff to bend things into a usable shape. Promote clueless managers and fire the brightest staff. Find more scapegoats as needed.
Notice how low your bank balance has gotten. Go out of business.

There are better ways. We'll leave vacation planning to you, but for development, the best thing to do is to...
  • Know your business needs.
  • Make only changes that fill those needs.
  • Keep things simple.
  • Work with people you know.
  • Rely on those you can trust.
  • Question everything and everyone, all the time.
  • Work in good faith.
  • Be honest.
  • Be open.
  • Be fair, adult, and considerate.
  • Understand that you don't know everything.
  • Stay flexible.
  • Do things only in small steps.
  • Learn from your mistakes.
  • Be grateful.
Be grateful for the chance to work, to make a difference, to be good, and to work with smart, caring, competent people. The rest is easy. (Or at least simpler.)

Do this, and it's like being on vacation all the time, but without a rubber raft stuck to the roof, or a trunk full of swim fins and hot, rattling golf clubs.


Wednesday, June 10, 2009

Information Architecture, part 1

Defining the definition.

What is information architecture?

Building a web site is more than decorating a web page with some words and pictures. Information architecture (sometimes called just IA) defines a site's content and organization:
  • What a web site shows.
  • How the site is laid out.
  • How the site can be navigated.
Think of information architecture as a blueprint for a web site. Information architecture is the foundation for building a high quality, usable site. Information architecture:
  • Delivers plans for design and development.
  • Provides an understanding of function.
  • Defines user interfaces.
Content, visual design, interaction design, usability, and functionality are also important, but the plan has to be there first. You need a good foundation. That's where information architecture comes in.

Why bother creating an information architecture?

Why? To meet business needs. Information architecture is a discipline geared toward meeting business needs. It's a way of creating plans to meet those business needs.

Information architecture goes beyond deciding what the content should be and where it should go. Instead of simply arranging pictures and blocks of copy, somehow, information architecture delivers concrete answers about how to help visitors find what they need and understand it when they find it.

Helping visitors is vital. No doubt about that. But the ultimate goal is to serve the business. Good information architecture results in a partnership between user needs and business needs. The point is to meet everyone's needs.

Information architecture is more than just blindly accepting everything site visitors or site users say, and more than just making a single business client happy. An information architect has to understand a project's variables and create a balance that helps people find and manage information. Those people are both inside the business and outside the business. But the ultimate goal is to serve that business.

Deliverables to expect from an information architecture.

An information architect helps to create some or all of the following deliverables.
  • Personas. These define types of visitors expected -- who might use the site and what they might be after.

  • A content matrix. This lists each page in the site and identifies its content. It's like a site outline.

  • A site map, a diagram giving an overview of the web site's structure. How to navigate a site is a separate issue, but it does depend on the site's structure.

  • Page layouts. These describe types of content, placement of content, and what functional elements a page might have. They also describe navigation within a single web page. Diagrams are easy to grasp, but written notes add depth and critical details useful for designers and developers.

  • Page templates. These are required for medium to large sites but optional for many smaller sites. Page templates define boilerplate, the layout of recurring page elements such as site-wide and local navigation schemes, sidebars, and standard blocks of text. Page templates also help in building a content management system.


Monday, June 01, 2009

Personal, Personal, Personal

Communication. It's an art. It's necessary. It's easy. It's hard. It depends.

You can't escape communication, and you don't want to. You need it, I need it, every business needs it. It's really all we have. But it can kill you if you turn your back on it.

One thing you can do is to keep it personal. Make all conversations unique. Own them. Act as though you mean it, and do. In fact, this is what you have to do. Otherwise you lose people.

It always takes at least two to talk, and to talk you need something to say, and you need trust, and a common goal. And you need to work at it.

Bad communication is easy. Just don't try. Mumble. Treat people like you don't care, which you don't, if bad communication is your goal.

Bad communication is avoidable communication. It's avoidable contact. It's avoidance in every way possible. Don't talk, don't write, don't answer the phone. Skip eye contact. Drone. Never smile. Join the undead. Escape reality. Escape involvement. Escape context. Escape business. Be vague. Be forgettable.

Bad communication is pointless communication. It never stands its ground, or gains any. Say something today and something else tomorrow. Forget. Make random noises with your mouth, put random words into your ads, build a random web site. It doesn't matter. Whatever.

Make no sense. Equivocate. Break promises. Represent nothing. Claim you didn't mean it. Concede the high ground. Keep at it until you are all alone. That's your measure of success.

Bad communication is simple communication. It's so simple that you don't need to think about it at all, ever. It's really that simple. You never need to worry about what you say or do because it doesn't matter. You can do anything. Or do nothing. OK either way.

If you want to communicate poorly then you don't work at it. Who wants work? Not you. You want to keep it simple. As simple as possible. Simpler.

No need to make sure you're being understood. Or make sure that you have understood. Or that you're making sense. Sounds like a plan, which may be a sign of too much work. Why bother? Try less, less hard, less often. Give up.

Bad communication fits all sizes. No tailoring a message to the audience. Stock phrases work great. After all, who cares anyway? Too much like work. Didn't we already cover that work thing?

Remember that you're going for the steady state of zero communication, zero contact, zero activity, zero complexity, zero gain. So don't bother checking who you're talking to or about what. Make something up. Anything. It will do.

Then, once you've learned this easy technique, keep it handy. Pull it out for any and all occasions. Why worry about who you're talking to? They're only people, and people are people. All the same. Numbers. If they don't like you they can go somewhere else.

It's not as though you want to have a relationship with anyone. Or like, care. Any place, any time, any people -- doesn't matter. Bad communication works on all of them.

On the other hand you might consider another point of view.

  • That no matter what you do, you are communicating something. You can't avoid it.
  • That whomever you are dealing with will remember what you said and expect you to stand by it.
  • That communicating takes work, and thought, and perseverance, and integrity.
  • That if you want customers, you have to treat them with respect, as unique individuals with unique problems to solve.

So then, do you expect your web site to communicate well or not?

If not, then why have a web site?

But if you have a web site, why not have a great web site?

Remember, you can throw a few dollars at a wall and get nothing more than flying shadows. A good site doesn't cost much more than a bad one, and you get a relationship at no extra cost. A solid communicating relationship with someone you can trust, who does good work, and who will help you gain and hold business rather than losing it.

Because the downside of bad communication isn't simply gaining less. It's losing what you already have.

Or was that what you wanted?


Wednesday, May 20, 2009

Would You Mind Communicating That?

To sum up then, Fred Brooks said "Adding manpower to a late software project makes it later."

Web sites are visible software.

Instead of saying manpower (which is valid) you can also say words (also valid). As in: "Adding words to improve communication makes communication impossible." True. Sort of. Sort of not. When in doubt, assume the worst. We're talking communication here.

The main problem is that there are no simple, clear, unvarying rules. This is an art. If software development were surgery then those involved would end up in pieces. Mommy and Daddy would never come home from work. There would be blood on the tracks and everywhere else.

Web sites are communication. Web development, communication, are not mechanical processes. People keep trying that approach though. You've seen the results. Those $10 web sites that you can't understand or navigate. The ones that look and work just like all the other ones you can't figure out.

And they expect you to trust them with your credit card?

Fred Brooks worked in a different world than we do. He was a manager at IBM when IBM was betting the business on OS/360, an all-seeing, all-knowing, all-powerful operating system for their mainframe computers. Those were huge beasts that could barely be steered. Imagine a woolly mammoth on a leash of dental floss. Like that.

IBM thought they could do better so they took a running leap off a cliff. Everyone learned on the way down.

They made the beast fly, but only by luck and sweat and swearing and lack of real competition. Partly luck, it's true.

Here's a central concept: your communication channels increase by the square of the numbers involved.

Say you have three people working. Three communication channels. Say you have 10 people working. More like 100 communication channels. IBM had hundreds of people on that one project.

Makes you dizzy.

Now instead of people think words. Same deal. The more you say, the more you have going on, the less you communicate. The opposite is also true though. Nice pickle to be in, right?

Say too much, or in the wrong way, and you have a confused mess. You need footnotes and outlines. Study guides, dictionaries. Tutors. You have to call in people with degrees (and lawyers too) to untangle the mess.

But say too little and you have nothing at all. Imagine a bouquet of flowers that's all stems and no blossoms. Ineffective. Pointless. Embarrassing. Scratchy.

All this is true.

Communication is hard. You have to work at it. It is a professional discipline. It has rules. There are pitfalls. It takes constant vigilance. There is no certified plan, no glory road to success. What works, works, and vice versa. But it isn't always easy to figure out which is which. You are never done.

Say what everyone else says, in the same way, and you vanish in the noise. Bad move. Don't sound like someone else. You need words that identify you, excite you, express your dreams, prove your expertise, shout with joy, electrify others, reel them in.

So study the best. Read. Let yourself stumble upon delight in the world. You will be better, your words too. Don't copy. Don't pretend. Work at finding out who you are and what you really do. Then say that.

See if it works. Keep trying.

You will know when you're getting close. People won't leave you alone.


Wednesday, May 13, 2009

An Echo Of Milton Glaser's 10

For the original, see "Ten Things I Have Learned", by Milton Glaser

1 You can only work for people that you like.

This depends on what you mean by work, but it seems like the key word here is "for". I prefer "with". It's possible to work for almost anyone, but possible only to work with those whom you trust, admire, feel comfortable with, and are inspired by. And then it isn't work anyway.

2 If you have a choice never have a job.

There is a quick test for job security. If someone can walk up to you any day, at any time, and say "You're fired", then you have a job. If you have a job you can lose it. And in this case it's worse, since any random drone can take it away. Go back to item one, look at it, and try to find the place and the people that make you want to sing.

3 Some people are toxic. Avoid them.

Think about it. Are you spending your time with people who are sore losers, and also sore winners? Are they obsessed with fear, hate, and greed? Toxicity always revolves around those qualities. Toxic people focus on the past and fear the future. They're always gnawing on an old bone and growling. There is no hope, and never even a feeling of freedom. Being with them is being in prison.

4 Professionalism is not enough or the good is the enemy of the great.

To the novice anything is possible, but to the expert, at best, only one thing is. I've worked with people who defined professionalism as being what clothes you wore, or even better, the act of wearing a tie. Professionalism in its best sense spins off of what people do but never inspires their actions. Procedures are for drones. Policies define broad guidelines within which humans can be human and use their own judgement.

5 Less is not necessarily more.

Sometimes less is only less. Sometimes more is only more. It's best to start by knowing what you are doing and what you need to get done. Then you can add or delete to sharpen your point.

6 Style is not to be trusted.

Style is like professionalism. It comes from the work but doesn't create the work. If style was really important then there would never be a new style. Styles would be immutable. Style is a byproduct of creativity and simply falls out. Not everyone can create a style or even follow one, and anyway it is a result of reflection and analysis and not inherent.

7 How you live changes your brain.

This is subtle but obvious. The only requirement is to pay attention and then you'll see it happen. Until I began photographing with transparency film did I not notice how blue shadows are. That was years ago, and it's still with me. If you aren't a photographer or a careful painter you won't see this. The same applies to any creative endeavor. It takes constant work to be creative, and then after some while it continues to take effort, but the paths are well known.

8 Doubt is better than certainty.

I remember hearing Anne Lamott say that the opposite of faith is not doubt but certainty. Certainty equates to hubris. Hubris equates to aggressive stupidity. Stupidity is not good. Doubt is a gentle guide which can lead one to unexpected and wonderful places. Doubt is better than certainty. Any day.

9 On aging.

It doesn't matter, as Glaser says. Noting matters. We're all dead. Cemeteries are full of indispensable people. Even if age did matter, what are you going to do about it? Really. Stop to think for a while and you realize that life itself is horrific. No matter who you are or what's going on, you get to this conclusion. The next step is to ask yourself what you're going to do about it. It doesn't matter. You can go on and see what happens next, or not go on. You'll get to the "not go on" soon enough no matter what. No one really knows what life is or if it's got a point. The universe does not care. If it cared then everything wouldn't be eating everything else. Did it ever occur to you what a huge waste it is for one animal to be eaten by another, or for millions of plants to be eaten before they reproduce? The universe doesn't care. It's overflowing with waste and loss. Therefore it must not be waste and loss. Somehow. Or else we have no clue at all. I don't think we have a clue. It doesn't matter. This is a rich place. It can throw us away, all of us, and never notice.

10 Tell the truth.

Lie to others and you are lying to yourself. Lie to yourself and you are lost. Therefore do not lie. There will be trouble because of the truth, but trouble is all life is anyway. It's idiots all the way down. Euripides: "Talk sense to a fool and he calls you foolish." Right?

Wednesday, May 06, 2009

I Was Once A Drone Too

Easy target. Gummint. Drones.

I heard last night that someone I know is going to lose his job. He works for the state Parks and Recreation Commission. They're getting hit hard.

He seems to be an OK person. Don't know him well. Didn't hear this from him.

The new state budget was announced about a week ago. Everyone is figuring out what to do between the beginning of May and the beginning of July, when the new budget kicks in. Apparently some places had it figured out in advance, and were only waiting to hear the official details. So the Parks people kicked in right away. They need to give 90 days of notice and all.

I can't say if he deserves to keep his job or not, but the Parks system is obviously not high on anyone's list of essentials. Not like schools, not like highways, not like law enforcement. Just one of those things that is so important until it's time to save money.

I spent a lot of years working for state governments. Two governments, about 20 years. In a way it was an advantage. I didn't earn all that much but over all it's more secure than some places, and I'm frugal. And beyond that, it gives you a great perspective on large organizations.

It's easy to criticize government but it's no different from any large company. Not that much. Aside from never ever being in danger of closing there really isn't much difference.
Even bureacrats need something to read.

"If you take two parts pathological aversion to risk, mix it together with one part apathy and a jigger of laziness, what you get is the government workforce culture" applies all around. *

I've seen it.

Over the years I developed a rule of thumb. Of the people you work with, one third do the work, one third do nothing, and one third actively screws things up.

The corollary is that incompetence is rewarded and competence is punished. Do good work, work hard, be dependable, and you'll be given someone else's work to do as well. Management prefers to avoid those who are completely undependable or who cannot be awakened. So they pick up the work of those people and dump it on the good ones, who feel guilty that they can't get it all done.

And then they get angry.

And then they get bitter.

And then they leave.

Guess who gets left on the job?

I have to say that I can sum up all of my experience and all of the problems of a large organization in two words: incompetent management.

I don't know if this guy I heard about was good or bad at what he did, but it isn't his fault. When the current governor came in, she was planning to improve things. It isn't all her fault. All of them are to blame.

The legislature meets for a month or two, passes laws, and goes home. The governor passes instructions to the heads of the various agencies, and then goes back to glad handing and planning for the next campaign. And whatever else governors do. Then the heads of the various agencies turn to their lackeys and pass the instructions along, and go back to lying to each other and continuing political knife fights. And so on down the line.

The best people in the system are at the bottom. They take things seriously. They believe in what they are doing and keep things running. And they make the least and have no power.

After a while, a year or two, or five, everyone gets to a common level. No matter who you are, what your talents are, how good you are, how much ambition you have, all you want to do is to live long enough to retire. You just want to get through today, and tomorrow and so on, and get that never ending basket of fruit and sit down and wait to die.

This is not good.

I've looked around a few times and decided that things could be run with almost no staff, compared to what I've been in the middle of. I realized this pretty clearly when I was in an office of 50 programmers and analysts and managers and so on and heard that Borland Delphi was built and maintained with fewer than 10 people. A product that worked well and was sold world wide.

All of us could barely keep our bag of rats working from day to day. It took weeks to get a meeting, and then no one made decisions. We had no contact with our customers or understanding of what they did. No training, no tools, no incentive. We were all hoping to get in enough years to retire, wave goodbye with one finger, and retreat to lawn chairs where we could finish our days swearing to ourselves about our wasted lives and talents.

So the governor came in four years ago and had a big plan and nothing happened. It could have but it didn't. Then the next election came. Then the economy tanked. Then the legislature met, and cut. Now people are wondering how long they can live in their cars, and when they will have to eat their pets or sell their children.

You can bet that almost everyone in management at any level of management, is going to stay. Because they are so important. They will have to keep the flame and pass along the secret knowledge about how to mumble, shuffle, obfuscate, intimidate, delay, and dodge.

The watchword was always "wait". Can't do that now, wait. Not ready for that, wait. We don't have the resources, wait. Not enough staff, wait. You're way ahead of everyone, wait.

In 2003 I was pushing to switch to Microsoft's .Net technology. I ran an agency's internet site. Though web stuff was new to me I had experience in other platforms, and two degrees. I taught myself HTML, CSS, ASP. I became good. Then I sent myself to .Net training and paid for it with my own money. And they didn't care. Six years later they're still running the web site on ASP. They don't care.

If the budget collapses they'll just shed a few expendables. They don't care.

Things won't get done. They don't care.

A few children will die. They don't care.

They never have.

Every six months or so a child dies in this state in foster care, or from an abusive parent. Big news, big time. In all the papers. On all the broadcast stations. Gigantic fuss.

Six weeks later everyone has forgotten. Management waits. Wait long enough and every problem solves itself by being forgotten.

Then another child dies. Same story. Wait. Wait. Wait.

Everyone forgets. Nothing happens. System continues on autopilot.

I worked with some intensely intelligent people. People who knew the whole social worker system, the laws, right and wrong, knew what was good and bad. Too bad they didn't run the place.

I had quit a permanent job to come aboard as a temp just so I could make a difference. Worked hard. Did things no one else could do, or was trying to do. We were on a project to rebuild the whole old mainframe system as modern software.

Then after a while we saw some contractors. Then more. Before too long the contractors were running everything. They didn't even talk to us. I managed to switch to web work, and after a while longer got on at another agency doing data warehouse work.

The original project continued, ever inflating. Two of us, with another four or five well chosen people, could have finished a bare bones but rock solid implementation in a year. Guess what. Everyone liked all those contractors buzzing around, looking important, using big words, making $200,000 a year compared to our $40,000. Obviously, since we were making less we were not as good, so more contractors appeared and pushed out all the regular staff. One guy played online poker at his desk. Others read the newspaper. And so on.

About two years after I left the whole thing collapsed. Only a small glitch, about $12 to $14 million, I guess. Throw it away and start over for the third time. Or was it the fourth? No one cared. Too little money to fuss over.

So now people are losing their jobs. Too many people, too little money.

Nobody thought ahead. No one who was important. Funny how they never do. They just wait. This will blow over too, and then they'll celebrate with another coffee break and hire more staff because they're so overworked.

Right. It's true. They get so fatigued thinking about all the things they'll have to do someday that they want to go and take naps to recover in advance. To nap, perchance to dream. To dream, perchance to see all those fresh compliant staffers whose head count alone indicates how important you are. Just wait. They'll be flowing in the doors one day, and we'll all be important again. And then, after one last coffee break we'll get to retire and finally switch off for good.


* The Register