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?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.
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.
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 2:16 AM
Homestar Runner does it again.
Client cluelessness: Your biggest challenge.
November 18, 2002 1:14 AM
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*
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.
For the third time, no!
November 12, 2002 8:46 AM
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 4, 2002 10:21 AM
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...
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.
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.
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: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.
> screenshot(s) of the "before" design
> screenshot(s) of "after"
> why the change was made
> the before vs. after numbers
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 ;^)