[kde-guidelines] Styleguide, Section 1 (Vision, Persona, Scenario)

[Thomas Pfeiffer]

On 03.02.2014 10:16, Björn Balazs wrote:
> Am Sonntag, 2. Februar 2014, 20:18:49 schrieb Thomas Pfeiffer:
>> On Thursday 30 January 2014 21:26:12 Björn Balazs wrote:
>>> Am Donnerstag, 30. Januar 2014, 14:12:23 schrieb Thomas Pfeiffer:
>>>> On 30.01.2014 11:04, Björn Balazs wrote:
>>>>> Thanks for adding the sections! Great work!
>>>>>
>>>>> Concerning the examples:
>>>>>
>>>>> For personas, I think we should try to find KDE wide personas and
>>>>> projects
>>>>> should be encouraged to pick the best fitting ones. But as for vision
>>>>> and
>>>>> scenario, they should also be allowed to create their own. We should
>>>>> somehow create a pool of real world examples for each artefact. So if
>>>>> KTP
>>>>> wants to actually work on these artefacts the results need to be
>>>>> easily
>>>>> accessible, just like those from any other project...
>>>>
>>>> Given that I hosted the session about the creation KDE-wide personas at
>>>> last year's Akademy, I think my position on those is clear ;)
>>>
>>> Perfect. We could even try to figure out 'classes' of KDE applications and
>>> suggest which personas could be used by them. This would be the same for
>>> other shared artefacts.
>>
>> I'm not sure whether we should do that, or whether we should leave it to the
>> projects to decide which user group they want to target. For example if
>> there is a persona for a student who uses KDE software at school, that
>> persona may be the first that comes to mind for educational applications,
>> but would be likely to use e.g. office or creative applications as well.
>> Then each office or creative application should decide whether they want to
>> target that persona or not, or they could decide to create an alternative
>> GUI specifically for the student persona.
>> For me, that would reflect our actual userbase better: There is no userbase
>> specific to a certain class of applications. There are users with certain
>> background or which use our software in certain contexts, but I assume many
>> of them use more than one class of applications (though some groups may
>> indeed use only one class of applications, or maybe even just a single
>> application and no other KDE applications).
>
> You know people are lazy :) - So I would never say: Use only these personas -
> but rather try to offer a set of personas, project can choose from if they
> like. If they do not find a suitable persona for their project, they can
> create their own, just using the other personas as templates (and then adding
> their persona to the pool of personas, so others can re-use them again).
>
> Summing it up: I would love to keep to ammount of personas as small as
> possible - I think this would even help to reach more consistency :)

Sure. I don't think we'll have that many distinct types of users anyway, 
so I think that goal can be reached either way. I assume we'll end up 
with maybe around five personas or so.
I just think that if one wants to make e.g. a software for instant 
messaging in the workplace, a persona for "An office worker who uses our 
software at his workplace, but not for his primary task" would be more 
helpful than a persona for "a person who uses instant messaging", 
because the former could be used for a whole range of applications, 
where the context is always the same.

>>>>> Also I would like to question the choice of artefacts. I like to use
>>>>> the
>>>>> metaphor of a stage play. When we want to find UX solutions, we need
>>>>> to
>>>>> understand some sample scenes of the interaction. Each scene (I would
>>>>> call
>>>>> this scenario) has some roles (persona) and there is a stage with some
>>>>> stuff on it (I like to call it situationa). The narrator will tell us
>>>>> about the feelings of the actor(s) (I like to call this animata) and
>>>>> what
>>>>> they want to achieve (the destinata) when they enter the stage (aka
>>>>> start
>>>>> the interaction with the to-be-designed tool)...
>>>>>
>>>>> Personas, Situationas and Animata can well be shared between the
>>>>> different
>>>>> KDE projects. Destinatas need to be defined individually (and hence
>>>>> the
>>>>> scenarios).
>>>>>
>>>>> The vision is sitting on top of it all :)
>>>>>
>>>>> What do you guys think?
>>>>
>>>> I like the theater/stage metaphor, but has it ever been used in this
>>>> context (including the proposed terminology) before? If not, I think the
>>>> method should be described in detail somewhere else beforehand, as I'm
>>>> not sure if HIGs are the right place to introduce a completely new
>>>> method. If you invented the concept and haven't had the chance to try it
>>>> out yet, KDE could of course be a test candidate, but I strongly prefer
>>>> to have HIGs based on tried and true knowledge, so I'd then prefer to
>>>> test how well the stage metaphor works with a few KDE projects, then
>>>> publish it if it's successful and then put it into the HIG.
>>>> If others have used that metaphor with that terminology before, than we
>>>> can just link to a document describing it and it's fine with me to use
>>>> it in the HIG.
>>>
>>> We have used parts of it in different projects - it has not been applied
>>> though to such a project like KDE and also not as a whole. There is also
>>> no
>>> complete description of it available yet, as we did most of this for
>>> closed- source projects. So yes, this is an idea that is in my mind for
>>> not much more than a year perhaps and from the real-world tests we were
>>> able to do, I am quite optimistic that it has an advantage compared to
>>> other
>>> state-of-the-art methodologies.
>>>
>>> Your point concerning an external reference is valid though. But as the
>>> first part of the HIG which we are talking about here is only used by UX
>>> experts, we can understand the whole thing as 'work in progress' anyhow.
>>> The idea has to be shared by the currently active us, and then the
>>> documentation could also be an output of the project, so 'new' UX people
>>> can easily adopt to it.
>>>
>>> The metaphor of a theatre stage has the advantage over other
>>> methodologies,
>>> that non-UX-experts will have the chance to quite easily understand how
>>> the
>>> artefacts are related to each other and how they can be applied. It is not
>>> fundamentally different from any other methodology that puts a strong
>>> focus
>>> on Person and Situation - it is just a bit more structured and hence
>>> easier
>>> to apply.
>>>
>>> I still would not expect any project without proper UX support to fully
>>> comply with the 1st part of the HIG though. But that is independent of the
>>> methodology chosen...
>>
>> Hm okay, to summarize your suggestion: We don't advertise the first part of
>> the HIG to the rest of the community much for now, see how well things work
>> when we ourselves apply them, and then advertise it to new UX people?
>> Yes, that may work. I just don't want developers to think we're using
>> unproven methods on them.
>
> Agreed.

:)