[libreoffice-design] UX bug process

Hi guys,
I'd like there to be a clear step-by-step guide on how to report UX bugs.
Unfortunately, I don't really know how to report these bugs myself, so I'd
like to work with all of you to devise a clear process.
Fabiana Simoes lays out the ground rules in her "How to not report your UX
bug" GUADEC talk [1]. Her presentation talks about how UX bugs should
center on a problem rather than on a proposed solution. To give a real-life
example, the summary of a UX bug should be "Non-printing Characters are Not
Set Apart from Text" rather than "Give non-printing characters a color
different from the text", as the former describes the problem, encourages
discussion around the best solution, and makes the reasoning behind the
picked solution clear, whereas the latter proposes a solution right away
without questioning if it is the best solution.

As a start, I'd propose these guidelines:

1) In the Summary/Subject field, describe the problem, not the solution.
Rather than saying "X should be Y", say "I can't figure out how to X" or "I
expected X, but Y happened".

*The pieces of information that Fabiana says a user should provide [2] are
basically covered by the Bug submission assistant [3], but should be
mentioned in the guidelines nevertheless:
*
2) In the Description, mention what you were trying to accomplish, how you
tried to accomplish it, what you expected to happen, and what actually
happened.

3) In an additional comment, feel free to propose a solution. If your
proposal is long or includes mockups, put it on your user page on the TDF
wiki (https://wiki.documentfoundation.org/User:[your user name]) and
provide a link to it in the comment instead.



In regard to Whiteboards, the design team may decide to make one for a bug,
but I'd rather leave them out of the guidelines, as I don't want to see a
load of whiteboards being created without approval.

The solution should be agreed upon based on discussions in the bug
comments, on the design list, and on our IRC chats (all of which should be
linked to in the bug comments), using our UX principles [4] and guidelines
[5] to resolve controversies.

I'd also like to ask: What is the role of the ux-advise mailing list? Is it
a place for devs to ask designers for UX help or a place where designers
and devs can ask each other questions? When should a bug be tagged
"ux-advise"? Is it a component that should be used for all UX/UI bugs, both
confirmed and unconfirmed, until a solution is agreed upon?


P.S. elementary's UX bug process is also worth a look:
http://elementaryos.org/journal/so-you-fancy-yourself-a-designer

[1] http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug
[2]
* What were you trying to do?
* Why did you want to do it?
* What did you do?
* What happened?
* What were your expectations?
* What are you running?
[3] https://www.libreoffice.org/get-help/bug/
[4] https://wiki.documentfoundation.org/Design/Principles
[5] https://wiki.documentfoundation.org/Design/Guidelines

-- 
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted