Category Archive » Internet Consulting

Remember, it's 'show me the money.'
[ November 26, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

Normally I think Nathan Shedroff has a well tuned insight on web development efforts, but in this interview with him at V2 (a great site) he says something crazy...

The interviewer: I mean, come on, Nathan. Realistically, now. How many client projects are going to be able to afford their own dedicated Experience Designer? How many would be better served by a qualified IA who's maybe attended something like the AIGA conference - but used that as a conceptual overlay, informing a sound underlying architecture?

Nathan: How many can afford an IA? Of those who can, how many actually have one on board? This isn't an issue of money and budgets. It's one of context and approach. A good IA might also be into looking at the larger experience (beyond the information organization, presentation, and visualization issues). That's awesome. But that's more than the job description for IA.

Sorry, but it's all about the money. UI designers, UX specialists, Info Architects and the people they work with must always make value judgments on the tasks they are assigned, or take on themselves, and squeeze maximum value out of their efforts to complete the task.

Value judgments need to be made.

Is a week's worth of UI review and usability studies going to help the web app? Yes? Do I have the time and money to do that? No? I don't care if 'context and approach' are what Nathan thinks is important, the client thinks quality at a low price is importent, so we need to make efforts to satisfy that need. Context, approach and good intentions don't pay the mortgage.


Web development boiled down to the essential truths.
[ November 21, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

Homestar Runner does it again.


Client cluelessness: Your biggest challenge.
[ November 18, 2002 | Permalink | 5 Comments | 0 TrackBack | TB URL ]

Many of us (us = me, and my 5 readers) have experience the anguish of enlightening the client of a given web development project in the interest of faithfully, and robustly executing the business plan of said client. The cluelessness, ignorance or otherwise diminished understanding of the realities of web development and web site/application development is a huge business risk.

Overcoming that problem requires the liberal arts major in all of us to find a way to understand, relate to, and transform the notions the client may have coming into a project. One of those core things the web professional needs to deal with is revealing the fluid nature of the web page itself.

I can't count using all of the follicles of hair on my body (there are many) how many times a client/business owner, 'stake holder' or 'the guy in charge' has asked...

Can that be moved down a little?

Of course it can! In fact, the code creating this page may automagically do that in one of the other multitudinous browsing environments available to the browsing public. Please understand that HTML is merely a suggestion on how to render a page. This isn't a magazine, it's a web site.

But, what I mean is, that's up to high and isn't really important.

Well, I know it's too high, because this page doesn't have the content you promised to deliver LAST WEEK so it's just a place holder, and the footer in question is near the top of the page for reason (this is where I edit the HTML in front of them, add in a ton of paragraph tags, and ask them to imagine the tardy content made it to school on time). Besides, it actually is important since it shows who owns the copyright here, and what the terms of service are (via a link).

Oh, I see. So, what content do I owe you?

*sigh*


Patterns of Use
[ November 14, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

<incoherent blathering>
When building a web site and working with a client, I often refer to patterns of use regarding how the current site (if any) is being used or how the upcoming site will be used. I often make the point that the user will find the easiest way they can to get maximum value out of the site. So why not make that pattern of use as easy as possible and adopt that system?

I have found that the pattern of use for this site has little to do with referrers from other sites, or browsing from page to page. I've provided links going forward and backwards from each page, and have put in links to categories of posts, but those links seem to be rarely used.

Most often, readers are using bookmarks to go to the home page or are using RSS aggregators to read the site. If this were a commercial site that earned cash from adverts, would I adopt the patterns of use that are evident from server logs? Probably not, and this shows a fundamental disconnect between how the business wants you to use the system and how the user wants to extract maximum value from it.
</incoherent blathering>


For the third time, no!
[ November 12, 2002 | Permalink | 7 Comments | 0 TrackBack | TB URL ]

When a client repeatedly asks for text to be scrolling back and forth on the site you are building for them, what do you say? The obvious answer being "no" hasn't worked since the request keeps coming. I keep trying to make the point that annoying people fails to generate business, but that doesn't to be as evident to the client as it is to me.

This is the hardest part of building sites for people who just don't get it.


Emergency Room visits are like working at a dot bomb.
[ November 04, 2002 | Permalink | 1 Comments | 0 TrackBack | TB URL ]

I have recently had cause to see lots of doctors and go to the emergency room, and I have to say that the entire system is a Process and User Experience disaster (and very much similar to an e-biz consulting company). Consider the following pattern...

1. I develop pains for some unknown reason, and it doesn't go away for a long time, so I drive myself to the emergency room.
2. Upon arriving I have to sign myself in, assuming of course that I can control my hands enough. The waiting begins, in a hospital that doesn't see high traffic, especially at this early hour of 5am.
3. The on-duty orderly type guy then calls me in after a while that and does the discovery session and gathers the requirements to solve my problem. He takes notes using a computer interface with lots of pop-up selections, causing massive amounts of clicking.
4. Next, I go back and wait, and then check in, again, with someone else who wants to know how I'm going to pay for this. Due to my condition, I don't care, but hand over my insurance card with a shaky hand. This person asks me the same questions as the other guy and enters them into a terminal looking application. this leads me to believe that my ailment demographics are being taken.
5. I wait again for the next round
6. I'm eventually invited into the back where all the good equipment, doctors and most importantly (for me at the time) where the drugs are. But, before I can some relief, I am interrogated again, but no one takes notes or enters this repeated info into a computer. This leads me to believe they know my ailment data has been recorded at least once and they can refer back to that if they need to, but reading that in the first place must take to long so they as me directly as I writhe around on a gurney.
7. Due to the symptoms, they decide to hook me up to an IV and pump all sorts of crap into me, and I attempt to be a good customer, er patient, by asking about everything they are doing.
8. I understand little to none of the info passed to me in spite of my St Elsewhere, er, and Dr. Quinn Medicine woman medical education.
10. The pain killers kick in, and I don't give a fuck about anything anymore.
11. More questions and answers, and lots of waiting. But who cares about waiting when you are in a stupor and have no sense of time passing.
12. Blood tests come back with some good news, but I only know what isn't wrong with me, not what is.
13. I know a bill will arrive in the mail soon.

This whole thing really feels like deliverables time on a dot bomb, death march project in 1999. You know, the urgent feelings that something is happening, but you are not sure what, and you try to do something about it, and the process is taking too long, but you get something done, and it feels great, but you still know nothing, and you know a bill is going to come in the mail, and you are hoping to god that your backers are going to make good on their commitments.


When prototyping, go for broke.
[ August 01, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

In Chris Farnum's article What an IA Should Know About Prototypes for User Testing, the issue of the 'degree of fidelity' is addressed...

Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You'll want to make a decision about the right approach for you based on the needs of your project.

I'll add in my two cents and say that the higher the fidelity the better, within the constraint of the cost of the prototype. As in, the more you can make the user forget about the medium of the prototype, and thus the more you can make them focus on what's important, the better. In my experience, clients, customers and users (often, all the same person/people) have a hard time getting around anything in the prototype that doesn't make sense. I have often had to fully immerse the user in the prototype by including relevant and current data in a prototype.

For example, I worked on a prototype of a Bond Trading web application, with full interactivity being emulated thru smoke and mirrors (aka, JavaScript). The client would always make comments about the dummied data I was using and how it didn't make sense. I had to go thru the trouble of getting real and current data to populate the prototype so they could get past the math they were doing in their heads and then get on with the business of evaluating the prototype.

Again, when the user/client was able to 'suspend their disbelief' (a term often used within the scope of watching a movie) due to a high fidelity prototype, they were more apt to comment on the interaction design and usability of the prototype. This point is made is made in Farnum's article, and I'm offering a concrete example.

Unfortunately, the higher the 'fidelity' of the prototype, the more it is going to cost, in terms of time and money (and time is money).

To go thru the effort of creating a prototype that is very similar to the envisioned finished product means you need to get real data, real information, real design and real effort involved. None of that is cheap, and will often dictate how realistic the prototype can be made. I my opinion, prototyping is like buying a computer. Figure out how much cash[time] you have to spend and buy the best thing you can afford.


Non-technical Project Managers.
[ June 21, 2002 | Permalink | 0 Comments | 1 TrackBack | TB URL ]

There's a great thread on Slashdot about Project Manager's and the decisions they make based on their experiences. I've lived thru a lot of what is described by the people posting to that thread, and the value of a clueful PM can't be over stated.


The change process can be a mine field.
[ March 31, 2002 | Permalink | 0 Comments | 1 TrackBack | TB URL ]

Jakob Nielson is doing a report on the cost of design changes and is soliciting data from you. In my experience, the cost of change is high and inevitable. The inevitability rises from the client always having their objectives thought out (to some degree at least) but often hasn't thought about how it's going to be accomplished. When you start building something (and writing in proverbial stone), they can see it, and the change requests start coming in.

A part of succesfully managing changes (which keeps costs down) is documenting the requests and making estimates on how much the proposed changes will cost in terms of dollars and time. Prioritizing those changes, and deciding if they actually contribute to the success of the project (which can be a political situation) will help keep you on target. So, in the end, you might have the data that Jakob needs...

We need:
> screenshot(s) of the "before" design
> screenshot(s) of "after"
> why the change was made
> the before vs. after numbers

Personally, I can't wait to see what sort of results come from this study. I've seen change processes devolve into a stream of conciousness that resulted in huge costs and missed deadlines.


Herding the cats.
[ March 03, 2002 | Permalink | 0 Comments | 1 TrackBack | TB URL ]

Web application/site development can be a long and multi-faceted process involving one or many people. If you know this already (newbie!), or are eager to learn more (masochist!), then you might want to look into 'Web ReDesign: Workflow that Works'. I picked it up a few days ago (45 well spent dollars at Barnes and Noble) and am happy to see it validating many of the work processes I have been involved with for the last two years. One point made has a particular resonance with me so far...

Having only one response to [a] Client Survey is particularly important because when working with several individuals you will get several opinions. The client, as a unit, must be aligned with common goals.

I have seen this in the wild, several times, in several different ways. Often, direction comes from all angles with no one person clearly in charge (and CYA activity is more important then ever). Sometimes there is one stakeholder, but they can't make up their own mind and attempt to make everyone they talk to happy. This is almost worse than getting it from all sides. Every once in a while, a client comes along who is on target, but they are usually other consultants ;^)


Removing the Barriers to Understanding
[ December 06, 2001 | Permalink | 0 Comments ]

Over the past two years I have found myself doing a lot of web application prototyping. It means a lot of (D)HTML, CSS and JavaScript coding, all with the hope of representing business requirements (in a way that is actually doable on the web). One major issue on every prototype I have worked on is the content within the prototype.

Developers often talk about 'greeking' interfaces and content of sites, which means putting in a bunch of nonsense text where the real content should live (eg, dsfgsdfg sdfgsdfgsdfg sdfgsdfg). After all, Java developers aren't content developers and should not be wasting their time with content, but with how it is stored, processed and transported. This is a barrier to understanding that you have to remove. [more...]