As this year's GUADEC is coming to an end I'm publishing an interesting update from Petr Muller for those who were not able to attend. Petr is a Senior Quality Engineer at Red Hat. His notes were sent to an internal QE mailing list and re-published with permission.
As this year's GUADEC happened in the same building where I have my
other office, I decided to attend. I'm sharing my notes from the two
sessions I consider to be especially interesting for the audience of
this mailing list:
== How to not report your UX bug ==
Speaker: Fabiana Simões
Blog: http://fabianapsimoes.wordpress.com/
Twitter: https://twitter.com/fabianapsimoes
Do not do this stuff:
* Do not simply present a preferred solution, but describe a problem (a
difficulty you are having, etc.)
* Do not use "This sucks" idiom, not even hidden in false niceties like
"It's not user friendly"
* Do not talk for majority, when you are not entitled to ("most users
would like")
* Do not consider all UX issues as minor: an inability to do stuff is
not a minor issue
What is actually interesting for the designer in a report?
* What were you trying to do?
* Why did you want to do it?
* What did you do?
* What happened?
* What were your expectations?
More notes
* Write as much as needed
* Describe what you see, did and *how you felt*
* Print screen is your friend!
* *Give praise*
== Extreme containment measures: keeping bug reports under control ==
Speaker: Jean-Francois Fortin Tam
Homepage: http://jeff.ecchi.ca
Twitter: https://twitter.com/nekohayo
Discussed the problem lot of OS projects are having: lot of useless
(old, irrelevant, waiting for decision no one wants to make) bug/rfe
reports in their bug tracking systems. Lots of food for thought about
our own projects, internal or external. Clever applications of
principles from personal productivity systems such as GTD and Inbox Zero
for bug tracking.
The talk was mostly an applied version of this blog post, which is worth
reading:
http://jeff.ecchi.ca/blog/2012/10/08/reducing-our-core-apps-software-inventory/
I particularly like the UX bug reporting guide lines. Need to take those into account when reporting UI issues.
I still haven't read the second blog post which also looks interesting although not very applicable to me. After all I'm the person reporting bugs not the one who decides what and when gets fixed.
Comments !