• Referring to people as “resources” – This to me is a return to the Henry Ford style of management. Treat people as you would steel or rubber or oil. They are interchangeable with little differentiation in quality. When you run out of resources, get more. A developer is a developer, BA a BA…it doesn’t matter, just slot them and tell them what to do. Meanwhile your real talent is walking out the door…because that’s what people do  when they don’t feel valued. Even worse, your real talent stays, but don’t contribute their brilliance because they are treated as  just another resource. (Eventually they’ll either be or be with your biggest competitor).

• Ignore Over-Allocation – MS Project has great tools to help you plan and schedule tasks, allocate people to work on tasks, reporting, etc. What’s the point in building a great list of tasks and laboring over dependencies if you don’t address over-allocations. I can’t think of a project I’ve been on where the PM gave two shits about over-allocation.  They worry about it for sure, but figure employees will step and be supermen and women and get it done so why hire enough staff to truly get it done. Project is there to help you figure out how many people you’ll need to get the job done, not at as a glorified task list.

• Take Care of Dependencies – Listen to your subject matter experts when creating dependencies. Most of them aren’t making stuff up. They know what is needed to get the job done…and they aren’t necessarily your IT “buddies”. Most IT people don’t know squat about marketing, training, technical writing, sales, etc. so don’t count on them to create those dependencies correctly. Contact SMEs in that field and ask for their help…even if they are not on the project.

• Use PM to Drive the Delivery Date – Ask yourself: What exactly is the point of going through a big project management exercise if you are driving toward a pre-determined delivery date pulled out of the air?  This is a tough one because so many business leaders think it is a “leadership skill” to pick some arbitrary delivery date based on…something often completely unrelated to what they are trying to accomplish. You really want to work with someone who thinks this way? You think he doesn’t have something else up his sleeve in the future (withholding payment, change requests galore, etc.)?

Using Project is a great way to get things done, just use it the way it is intended to and you’ll be fine. If you don’t, it is just a sad joke.

Much is common sense sort of stuff. For example unemployed people do more household chores than employed people. I can relate to that, I do a heck of alot more around the house since I’ve been out of work.

What I find most striking is how little time we spend thinking and relaxing. With all the problems going on in the world, I wish we’d take more time thinking about solving those problems instead of working and watching TV.

MP3 version.

I’ve used various Linux distributions over the years and have always gone back to Windows or the Mac because, for the most part, these proprietary operating systems WORK. In my experieince I’ve had little to no hardware issues, good software support and regular updates that…mostly…don’t break anything. As much as I’d like to to use it, I’ve not been able to say that about Linux .

Check out this, not so skillfully produced, video from Bryan Lunduke that speaks to the inherent “brokenness” of the OS that anyone who’s dabbled in Linux has run into. (It starts with issues getting the projector setup!) You can also download the slides as well. ]]> http://jeffholmes.com/2009/05/linux-sorta-sucks/feed/ 0 http://jeffholmes.com/2009/05/10-misconceptions-about-user-experience-design/ http://jeffholmes.com/2009/05/10-misconceptions-about-user-experience-design/#comments Sun, 24 May 2009 18:06:52 +0000 jeff http://jeffholmes.com/?p=54

Whitney Hess does a great job in 10 Most Common Misconceptions About User Experience Design. I especially liked number 8.

8. …the role of one person or department
User experience designers are liaisons, not subject matter experts, doctors or any type of magical beings. We don’t have a set of best practices that we can robotically implement, nor do we have all of the answers. Our greatest skill is that we know how to listen. While we can help evangelize the most effective process within your organization, it’s ultimately up to all members of the business to make it a success.

Listening is key. Whether it is in training a user how to interact with an application or observing them while the test it, they have a story to tell you. Their problems, fears, challenges and delights are dying to be heard.

I’ve been evangelizing about this at my company since before I even new what usability was. I saw people struggling with parts of the software we were developing and I felt for them. I joined the organization as a trainer and had seen people struggle with using off-the-shelf software. It seemed there was little I could do about improving it, but darn it, on tools we were developing, there must be an opportunity to influence how it was being built.

I’m sure my colleagues found me annoying (they almost said as much) with constantly asking questions along the lines of  “Why do it we do it this way?” “People aren’t getting this” , but over time I’ve begun to have some influence over them on how our applications are built. I didn’t have much luck though until I began to talk more formally with our users. It’s not like I had some sort of questionnaire, I just really began asking them serious questions about what they liked and didn’t like about using the tools we were building for them. Reporting back their responses, I found, added credibility to what I was saying and some validation for my critiques. Slowly, people (management and developers) began to listen.

I’ve learned that users hold one of the keys to building usable applications. For the most part, they are eager to contribute to the development process; if only you ask. Informally, I’d say about 90% of the people I ask to help evaluate new tools we are developing, say “Yes”. Sometimes it’s very formal with questionnaires and structured testing, other times it’s looser with just simple questions like “What do you think of this?” or “Is this something you’d use?”

The key action step is to ask. If you don’t ask for feedback from the outside, the only feedback you’ll get is from the inside. Certainly you need that internal feedback, but insiders aren’t the only ones using the tool. Sometimes they never use it. Your users, meaning the people who actually use the application, are the ones you need to be talking to.

Do people really want to interact with their walls? I can see niche applications for this kind of technology, home automation, graphic design, the military, etc. but for the average user I am grasping at a reason to drink the potion. Are we not all just a bit overwhelmed with technology already? Why can’t we just make what we have better? I want my computer to have instant on…today. How long is it going to take for your wall to boot up in 2019?

As professionals we are often pressured to make human computer interactions cheery and pleasant and to defer to the expertise of the user, while those are certainly noble and worthwhile objectives, common sense and ethical considerations also play a role in the design of software applications. Advocating for transparency and full disclosure is good for the customer and the bottom line.

How many of these industry executives would have taken the risks they did had their models balanced the rosy profit potential on equal footing with the potential downside? Likely some would have anyway but I am an optimist when it comes to human nature and I think people are essentially good, moral and ethical. I believe many others would not have risked their companies and reputations had they clearly been presented with all possible outcomes in straightforward and unequivocal terms.

http://sethgodin.typepad.com/seths_blog/2009/04/this-is-broken.html

From a usability standpoint, here are a few items I found interesting:

• “Poor-man’s eyetracking” “ About 5 seconds into each usability test, ask the person what they have looked at so far. They usually find it easy to tell you.
• Test stuff that your usability testees told you to change.
• If your website has a “cool” non-conventional layout, try a conventional layout. Conventions are conventions for a reason “ they make it easier for visitors to find what they are looking for.
• Use simple straightforward language. No reader is too sophisticated for short simple sentences.

There are 101 tips total, the focus is on e-commerce sites, but that doesn’t mean you won’t find them valuable for any kind of site.