Re: [libreoffice-design] Think, don't just do - WAS: Impress remote

Hi all,

trying to find some answers to the raised questions:

# Structure (of artifacts)

In my experience we will need to set-up at least the following artifacts (in 
whichever way we are going to produce them in the end):

1. Vision:

Here are two examples of visions:

"I believe that this nation should commit itself to achieving the goal, before 
this decade is out, of landing a man on the moon and returning him safely to 
the Earth." (John F. Kennedy, May 25, 1961)

"The iPod will be a portable digital music player that will hold 5000 songs. 
It will have a battery life measured in days, not hours. You will navigate the 
thousands of songs with a single finger. You will sync all your music from 
your computer to the iPod in minutes automatically, so you can have all your 
music in your pocket." (said to be formulated by Steve Jobs end of the 1990ies 
- might be an urban myth though...)

To sum it up
- The vision gives a clear goal (benefit) that helps to unify all people 
involved into making it become real
- It is commonly understandable and does not provide technical solutions
- leaves enough room for creativity
- helps to provide criteria so that different people in similar situations 
will likely come to the similar decission
- is short and hence present to everyone involved into the process

-> We would have to involve all LibreOffice people to find this vision. This 
cannot be tested or validated with users. It provides the frame we want to 
achieve. 


2. Personas:

Personas help us to understand and focus on certains users. Personas can be 
validated and quality assured by the users. Hope creating and working with 
personas is known to people on this list.


3. Situationas

Situationas are the situation / setting equivalent to Personas. They help us 
to understand in which situations / environments our product is beeing used. 
These can again be validated and quality assured by the users.


4. Goals / Core Usability Goals

When we place a Personas into a Situationa, we can understand the goals a 
person has in this situation. Yes, this gives a matirx that can be large. But 
again, we can validate and quality assure these with the users. From these 
goal we can derive the actual usability goals (e.g. learnability, Error prone, 
don't feel stupid,...) that can help us to design and later on meassure the 
success of our designs in usability tests.


5. Features / Szenarios

On this basis we can derive the actually needed features by creating szenarios 
of the usage. Again this can be tested with the users by using imagination 
techniques. These can also lead to wireframes or other mock-ups of the 
intended solution, so this is actually the bridge to design...


# Do we need to do user research for every project?

No. If we have these foundations we can build upon, we only need to do user 
research if we encounter any gaps. Usually the above mentioned artifacts 
should be created rather independently to current project. But staying real - 
it makes most sense to only create the artifacts that are currently needed. 
This way all the artifacts are created over time.

So instead of a workflow for every project, I propose to rather create sets of 
artifacts that every project would have to refer to, to reason the created 
solutions - but every project needs a maximum of freedom how to solve the 
problem. People are very different how they work. The task might be very 
different and needs different approaches...


# Tool?

With OpenUsabilily, KDE and other free software products, we are working on a 
tool, that helps us to actually do these things. This tool (User Weave) will 
be published under an aGPL soonish. My company wil then sponsor the hosting of 
this tool, so we can easily use it for our purposes, without having to deal 
with technical issues... So I would be happy if we would use and improve this 
tool for our needs. What do you think?


# Start?

We need to start at the beginning. Let's start to work on a common vision for 
LibreOffice. We will need a small team that conducts a couple of surveys in 
order to get feedback from the community - it would be perfect if we would 
finish this process in time for the LibreOffice Conference - just to give you 
an idea about the length of such a process...

Paralle we could use user-surverys (such as the proposed work on the iconset) 
to gather information about our users in order to create first sets of 
personas.


Ok, so much for today. I am curious for your thoughts on this....

Cheers,
Björn

Am Mittwoch, 9. Mai 2012, 11:58:42 schrieb Jay Lozier:
> On 05/09/2012 07:14 AM, Mirek M. wrote:
> > Hi Bjorn,
> >
> > 2012/5/9 Björn Balazs<b@lazs.de>
> >
> > > Hi all,
> > >
> > > just a short additional note - a more detailed answer will follow in the
> > > next
> > > days:
> > >
> > > Please do not mix up user testing user research.
> > :D funny, I was convinced this whole time that you were talking about user
> >
> > testing
> > oh well...
> >
> > > RESEARCH is about understanding (and creating artifacts accordingly) who
> > > the
> > > users are, what they (want to) use the product for, what goals they want
> > > to
> > > reach, what criteria apply to a successfull interaction, what prior
> > > experience
> > > they have, where they will use the tool,.... This can perfectly be done
> > > in
> > > distributed teams using web tools. We can reach users all over the world.
> > > Past
> > > experience in Libre Office has shown that it is easy to get feedback from
> > > more
> > > than 10000 actual users within days. And these were just first tries...
> >
> > What tools do you suggest to use?
> > Should every project we work on be preceded by a survey on the topic?
>
> It probably depends on the project. Some should be discussed on the list
> before asking user opinions. This partly to avoid survey fatigue and
> partly to allow us to think through the ideas before asking for user
> opinions.
>
> Other ideas may be generated by asking the users what they think should
> be done.
>
> > TESTING is about presenting users with possible solutions, and watching
> > how
> >
> > > they solve given tasks. This usually is extremely difficult to do with
> > > voluntary development teams, as you would need test rooms, local, but
> > > still
> > > representative - perhaps even paid - participants etc. There might be
> > > some
> > > room for this on fairs or similar events, but I would rather not be too
> > > enthusiastic about testing. In my experience the value of testing is over
> > > estimated. Most user tests actually do post-hoc research. And the other
> > > way
> > > around, I found that tests following projects that did decent research
> > > did
> > > not
> > > reveal any significant new insights.
> >
> > I'd still like to do user testing if we could. I'm not sure if we'd need
> > special test rooms with local participants. Actually, I think just seeing
> > how people use the software would help, and that could be done simply by
> > people videotaping their friends/relatives according to some directions we
> > give them and putting the videos up on YouTube. It wouldn't be the most
> > professional thing to do, but it would undoubtedly help us understand our
> > users more, more than surveys or usage tracking extensions. It might be
> > especially interesting to watch how users coming from Office or iWork work
> > with our UI. (I guess that still falls under the umbrella of user
> > research,
> > though.)
>
> IMHO, the basic problem with user testing is that most users do not use
> any software package at optimum efficiency. They have a method that
> works well for their needs that is not the fastest or "easiest" method
> available.
>
> > > Summing it up: Lets do extensive user research - both because in Free
> > > Software
> > > we simply will never be in the situation to do extensive testing and
> > > because
> > > it is the more sustainable anyhow.
> > >
> > > As a sidenote: icons are something that can actually be user tested
> > > easily
> > > via
> > > the web, here research rather does not help that much in contrast. These
> > > different ways that are appropriate to reach our goals are part of the
> > > experience I would like to share with this group.
> > >
> > >
> > > This also is one of the
> > > reasons I do not think we need a standard workflow the way it is defined
> > > at
> > > the moment, but standard artefacts (see above), that need to be used in
> > > smart
> > > ways to reach the different goals we have.
> >
> > I agree that we need some standard artefacts, but I disagree we should let
> > go of our workflow. While it isn't perfect by any measure, it seems to be
> > a
> > step in the right direction. I've been subscribed to this list for about
> > two years now, maybe longer, and I've been sorely missing a standard way
> > of
> > working. It seemed that developers weren't really interested in the design
> > team, whiteboards were a mess of unfinished ideas that could never be
> > carried out to completion, any sort of UI work was fruitless, and we
> > weren't really collaborating -- everyone (including me) was doing his/her
> > own thing.
> > I'm afraid that if we didn't have any sort of defined workflow, we'd
> > revert
> > back to the chaos that came before, even with the various artefacts
> > defined. If you have a suggestion for a better workflow, please do voice
> > your opinion.
-- 
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

-- 
Unsubscribe instructions: E-mail to design+help@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