Pim/ux

Personas

This is mainly a copy&paste from the KDE4 personas . They offer a good starting point that we want to refine over time.

The main area of application is in medium to large size companies and institutional organisations. So we talk about people like Berna (office worker) or Santiago (decision maker) as the primary persona. The secondary persona is the private user with average knowledge (Susan) but also those with special needs like mailinglists (Philip).

What might still be missing is the Persona for a "Roadwarrior"

Office Worker

Berna is working as an office clerk in a big insurance. Although a smart person, she is very unsure when it comes to technology. Berna's major work is to check the details of insured events. She writes reports for her boss suggesting compensation payouts for the cases she deals with. Berna is a very precise person, and always solves her tasks accurately. Berna twice lost several hours of work because she didn't understand the options she was offered. Since then, she has been very careful when probing new functionality.

Decision Maker

Santiago works in management. For him, technology needs to be comfortable and make him feel smart. He travels to see customers and corresponds with them a lot.

Recreational User

While Susan seldom uses her computer for work, it has become an essential part of her social life. With her computer, she can be creative and spread this creativity in the world. She chats with her friends, shares music, playlists and other media, creates videos and uploads them to her web space, and runs a blog with her own style. She can't imagine a life without her laptop. Still, she is a fun person and does not want to worry about technical details. She expects her machine to work.

Scenarios

We probably need to do some actual user research for this. Until then the "User Actions" section should be enough.

User Actions

Mail

These useractions where created with a mobile usecase in mind. They offer us a nice feature set for the first desktop client as well.

Common

Actions that are part of regular usage of Mail, and thus should be presented prominently in the UI

• read up on new/important emails and decide what to do with them quickly
  • reply to sender/all/list
  • forward
  • move to trash / a favorite folder
  • mark as important/unread
  • Mark as spam (server side)
• write new emails from scratch
  • select to/cc/bcc
  • spellcheck (instant)
• switch accounts
• open favorite folder

Uncommon

Actions which are not performed every day, but more often than rarely. Should be accessible when needed, but may take a few steps to execute

• find specific old mail to look up some information
  • browse the folder hierarchy
  • Add a folder to favorite folders
• manage email
  • move to any folder
  • tag (if we want that)

• Show additional details for a mail (all headers, mail size etc.)

During email creation:

• send as urgent
• request disposition notification
• attach file
• switch signature insertion on/off
• encrypt/sign (only if PGP/SMIME is configured)
• format HTML mail

Rare

Actions that are performed only occasionally or only once at initial setup. Can be in separate UIs

• setup / configure
  • account(s)
  • encryption
  • signature
  • spellchecker

• create / manage filters
• import / export mail

HIG

Human Interface Guidelines (HIG) offer application designers and developers a set of recommendations for designing and developing user interfaces. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.

Desktop

We have good HIG for KDE created by the VDG. We should use them for the desktop applications.

https://techbase.kde.org/Projects/Usability/HIG

The OSX one is also worth looking at.

https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/DesignPrinciples.html

Mobile

There is also a KDE HIG for Mobile in creation. We could also think about following the Andorid HIG. Let us have a closer look at that when we start do design the mobile applications

Research & Testing

Personas & Scenarios

Contextual Inquiry

A quite expensive exploitative research method that produces the most valid results when it comes to user stories and scenarios. The researcher accompanies a user for one working day (or context) and observes her, occasionally asking questions. Every day / session is closed with an interview where the researcher asks the observed user based on his observations.

Asking Domain Experts

The cheaper alternative to contextual inquiry with a chance to miss out on vital observations.

Expectable Behaviour

The application behaves as expected, when the mental model of the user aligns with how the applications behaviour. A mental model is an explanation of a users thought process about how something works in the world. It plays a huge part in how "intuitively" and applications feels.

This can be tested formally with little effort. We can test the whole application navigation or single features. We should do this for every "User Action".

Mockups

A shared location for mockups would be nice. The VDG uses an ownclowd instance hosted by KDE.