Not sure if I'm more awed or baffled by the creative cheapness. (Note: the bottom part was broken, so they...yeah.)
Notes from one human about usability and accessibility of technology, human-centered design, and some random thoughts that may be tied quite loosely thereto. And stuff like that.
Friday, August 26, 2011
Huh.
Not sure if I'm more awed or baffled by the creative cheapness. (Note: the bottom part was broken, so they...yeah.)
Thursday, July 7, 2011
Curious signage
I wonder what happened that made them be so specific?
Seems like you could simply say, "NO MOTORIZED VEHICLES BEYOND THIS POINT." What's not to understand?
Seems like you could simply say, "NO MOTORIZED VEHICLES BEYOND THIS POINT." What's not to understand?
Friday, May 13, 2011
Let me guess: this experience was designed by someone in IT?
Scenario: filling out a "form" online to request a medical appointment. Click "Confirm Request", and receive this message:
Surprisingly, I don't have a big problem with the fact that the "form" is simply a pre-filled input area that I edited. I found it simple to understand and use, except for the intent of the "Voicemail" question: are they asking "Does your phone have voicemail capabilities?", or "May we leave a voicemail with your patient information in it?"
But the error condition AND its helpful messaging are atrocious for your average healthcare consumer.
Wednesday, April 6, 2011
Gmail Menu (or, "If Only They Had Asked Me")
If you use Gmail, and if you have multiple Gmail accounts, you may have noticed you can sign in to two at a time, and quickly switch between them. Well...sort of quickly. The menu looks like this:
Even if you are signed into another account, you must select Switch account. Then you get this:
Why not display the two accounts I'm signed into right away, and allow me to make my selection with one click? Here's a suggestion, in which I can do everything I did before, but without two menus.
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."
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
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
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"
Subscribe to:
Posts (Atom)




