Tuesday, March 29, 2011

Practicality (yes, another 'Tools' post)

There is a recent discussion on a LinkedIn group for information architects regarding requirements tools. The original poster asked for requirements analysis tool recommendations, and the responses have varied widely.

As the thread has gone on, it began to amuse me that here we are--business analysts and information architects--doing exactly what we shouldn't: recommending tools without knowing the requirements.

It's not a "one-size-fits-all" practice in which we work. Just like we as BA/IA/UXD folks wouldn't recommend a single technology solution or single user interface model for every business problem.

Many people swear by Axure, which is a great tool for developing high-fidelity prototypes. Rational is a great tool set for those who are using Rational Unified Process. For those using Agile, Rally can be a very effective tool. For us, a set of custom-designed Sharepoint web parts (in effect, spreadsheets on steroids) does the trick.

(A note on prototyping: I cannot recommend it enough as a technique for refining, as long as you identify the appropriate level of fidelity required to do the job. When we do high-fidelity prototypes, it can become challenging to manage customer expectations around delivery ("It looks like you're done, so why does detailed design and development take so much longer?"). Regarding the archaic tool set "Paper and Pen" (or "Pencil and Eraser", which are infinitely more efficient for people like me ), it may not be effective to rely on those for every situation. But the ubiquity of the digital camera makes taking a photo of a sketch--pencil or whiteboard--much more efficient for our internal processes than taking an extra hour or two creating a Visio wireframe or Axure mockup. And when you're charging your customer, an hour or two per use case can make a difference.) 

So, just like the work we do, I'd want to know more about the requirements of the organization or project before recommending a solution. So, as I try to boil it down, here are some key inquiry points:

- What processes do the tools need to support?

- How mature / flexible are those processes?

- What is the scope and scale of the projects you need to define?

- What are the types of requirements and level of detailed analysis you need to perform?

- Who is your audience for the outputs? Do you have capable, experienced developers and customers, or do they need a bit more hand-holding?

- How well-developed are your BA/IA skills? What techniques do you use for gathering requirements?

- What is your budget? We have none, so specialized tools aren't cost-effective for us. We are trying to be innovative by finding new uses for the enterprise tools we already have in place.

- Are there any regulatory or legal constraints that require a particular level of analysis or documentation rigor? That might prompt you to use a different toolset.

I'm sure there are several more....

So, the answer, as usual, is "It depends."

Monday, March 14, 2011

From the "Ah, the Irony" Department

We bought this can opener yesterday. It's the kind that doesn't leave sharp edges on the can or lid. We were amused to find it packaged in one of those rigid clamshell packages--you know: the kind with the really dangerous, sharp edges.

Do you know the recommended method for opening rigid clamshell packages to avoid injury? With a can opener.

If only we had one.

Friday, March 4, 2011

Design for Disability

"In the context of an environment or society that takes little or no account of impairment, people's activities can be limited and their social participation restricted. People are therefore disabled by the society they live in, not directly by their impairment." --Graham Pullin, "Design Meets Disability"