Brooke Baldwin

Something that I’ve been thinking about for awhile now is this idea that interfaces should be designed differently depending upon the generation of the target demographic.

After hearing Susan Weinschenck speak about this topic at this years’ UPA conference she got me thinking. Which got me reading.

In summary, each generation has a different relationship to and with technology. Their needs are different, their tolerances are different, and how integral technology is to their immediate lives is different.

Any additional suggestions on what else to read?

No Comments »

The Usability Professionals Association annual conference was held in Baltimore, Maryland for a week in June. For it I prepared a short discussion (they call them Idea Markets).

Here are the notes from the discussion - thanks to all who participated! Copyright is shared with UPA.

Idea Market Notes :: Back-end Usability: Going Beyond the GUI

 

2008 Usability Professionals Association International Conference

Presenter: Brooke Baldwin

Date: Friday, June 20, 2008

 

Discussion Notes

Proposed Questions: What non-GUI things impact the users’ experience? How do can as usability professionals deal with these issues?

 

Outcome:

1.       Meet the other people in the IT department, especially the non-development teams that you are unfamiliar with (e.g., disaster recovery, infrastructure, network operations, etc.).

2.       Learn about what these other teams do (use your skills as a user experience interviewer); learn how they do it; learn their lingo. This will help you to understand and ask how their work can impact the users’ experience.

 

a.       Disaster recovery – do they run a hot or cold DR? At what frequency is it tested? What happens when there is a failure of the website or application?

Tip: Custom error pages will help users understand the problem.

 

b.      Infrastructure – what kind of environment are they architecting? Is it clustered?

Tip: A clustered environment will minimize down-time for scheduled releases.

 

c.       Release management – how are scheduled releases managed? At what frequency and time of day/week?

Tip: Usage data may help determine appropriate release scheduling. Post any known downtimes for users to see.

 

d.      Network operations – what kind of network flow problems most commonly occur? Is there a way to design the application/website to mitigate these risk(s)?

Tip: Peak times may overload the network; require load testing beyond predicted user volumes (start at 10% more).

 

e.      Upgrading – who performs system upgrades? What is their process?

Tip: Partial upgrades may require less effort by the user. Review upgrade instructions.

 

f.        Installations – who performs installations? What is the process?

Tip: Review documentation.

 

g.       Severity 1 Calls – is there a root cause analysis after each Severity 1 call?

Tip: These analyses can provide opportunities for review and improvements to process and/or software (e.g., was a downed-system caused because there is a manual input that can be modified to remove the human element or perform a check and alert before execution?)

 

h.      Penetration Testing – is this performed on a yearly basis up to (but not causing) a denial of network service?

Tip: Ethical hacking and fuzz testing can test hardware, software, and data by looking for trapdoors, network weaknesses, etc.  Are there ways the design can enable system failure (e.g., putting SQL select statements in the URL string)?

 

3.       Understand that you’re moving into uncharted territory, the reactions you get may be hostile at first. Don’t try to drive any decisions until you have established good working relationships and have learned more about their process and work.

4.       Pick your battles.

 

Additional Suggestions:

1.       Bring a non-UX colleague to observe usability testing. Seeing is believing.

2.       Consider if different designs could help any down-stream team with issues they confront (e.g., create a RESTful design, bring data into session while user is performing another activity, use AJAX, etc.).  Seek input from teams outside of development.

 

No Comments »

A colleague of mine at work pointed me in the direction of this website, A List Apart today. So I read through a little bit of it and found this great article, “On Creativity” .

It kind of made my day to read such a well written article about something that I agree with, that creativity at work isn’t about expressing yourself but rather being creative means taking constraints and finding a (hopefully) elegant way to make those parameters work well. The article is on a site that is about designing and developing for the web, but I’d posit that his argument holds true for just about any kind of work.

Andy Rutledge, the author, writes

Creativity has nothing at all to do with self-expression or flamboyancy. Aside from the simple ability to create things, the most important feature of creativity is a highly developed perception filter that is somewhat less common than we’re led to believe. Despite what we were taught in school, we don’t all possess significant creativity, and fewer of us still have any skill at employing it. True, anyone can make something, and anyone can make something up. In this mundane sense, everyone is creative. But this basic truth belies the design-relevant definition of creativity, and ignores the fact that each one of us has different creative abilities.

I think he’s right. It’s not that hard to come up with some new idea, it’s hard to come up with some new idea that works and works well. Or even with some idea that’s not even new, but works well. How many of us are really willing to be rigorous in our thinking? And in our work? I think the right way to be creative is to come up with an idea and then keep asking if it works or fits or is right. And if the answer is no or yes, then trying to figure out why. Because the answer to why just might point you in the direction of the next right answer.

No Comments »