Brooke Baldwin

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 »

According to US News  & World Reports being a usability practitioner is a pretty good gig.

No Comments »