Personas #37
Personas #37
Conversation
|
|
||
| ## 1. Summary | ||
|
|
||
| Personas are fundamentally intended to provide meaningful information for design decisions. |
There was a problem hiding this comment.
| Personas are fundamentally intended to provide meaningful information for design decisions. | |
| Personas are fundamentally intended to provide meaningful information for design and development decisions. |
| Joomla is already using kind of personas on the website. The problem is that they are not really personas, but rather: | ||
| <!-- Document: Copy of User Profiles - from Marketing team --> |
There was a problem hiding this comment.
| Joomla is already using kind of personas on the website. The problem is that they are not really personas, but rather: | |
| <!-- Document: Copy of User Profiles - from Marketing team --> | |
| Joomla is already using kind of personas on the website. The problem is that they are not really personas, but introductory guides to using Joomla based on how an individual self-identifies among these groups: | |
| <!-- Document: Copy of User Profiles - from Marketing team --> |
| represent the average of a target group, but appear as persons who reveal patterns in their usage behaviour. For this | ||
| reason, companies often develop several representatives of a target group. | ||
|
|
||
| Sensis created a set of behavioral-based personas: <!-- Document: Copy of Personas delivered by Sensis --> |
There was a problem hiding this comment.
Would recommend linking to a different page with these instead of including them here; it's a lot of text that could be overwhelming and distracting from the main point of the document.
| team consistently has to build extensions to meet business needs, as AOE has done, and hopes Joomla will soon bring | ||
| emphasis to commercial and enterprise solutions. | ||
|
|
||
| Another set of personas was created by Marketing(?): <!-- Document: Copy of Personas for Joomla --> |
There was a problem hiding this comment.
Same as above; good to have for reference, but not to include all of it in here as these were probably created with a different purpose.
| ### 4.2 Role-based Personas | ||
|
|
||
| In the role-based approach, the focus is on the role of the user. The user is not described as a person, but as a role, | ||
| because personal background information such as CV, place of residence, marital status, age or income does not really | ||
| help applying the personas. The basis here is the job description, which describes requirements for personality, skills | ||
| and knowledge regardless of the person filling the position. | ||
|
|
||
| ### 4.3 User-Group-based Personas | ||
|
|
||
| This is similar to the role-based approach, but the focus is on the user group. User groups are differentiated according | ||
| to the way they use Joomla. | ||
| For this purpose, the activities in dealing with the CMS are divided into task areas that are as far as possible free of | ||
| overlap. | ||
| As a result, a real person usually holds more than one of these user roles. On the other hand, it is easier for those | ||
| responsible in the project to assess the impact on the groups. |
There was a problem hiding this comment.
These are essentially the same. :) Roles are not necessarily jobs or positions, though in many enterprise situations it DOES correlate with job positions.
I'd recommend referring to this approach as role-based to avoid confusion with permission user groups, but we could use user groups as a metaphor to help people understand that while the roles don't usually overlap, individuals can have more than one role.
|
|
||
| ## 1. User Groups | ||
|
|
||
| The name of a group consists of a noun that describes the relationship to the CMS. The name of a group MUST be unique. |
There was a problem hiding this comment.
| The name of a group consists of a noun that describes the relationship to the CMS. The name of a group MUST be unique. | |
| The name of a role consists of a noun that describes the relationship to the CMS. The name of a group MUST be unique. |
| * **Extension Developer** - A developer producing mass market extensions to make a living from it. | ||
| * **???** A developer producing bespoke applications on customer request based on the CMS. |
There was a problem hiding this comment.
| * **Extension Developer** - A developer producing mass market extensions to make a living from it. | |
| * **???** A developer producing bespoke applications on customer request based on the CMS. | |
| * **Commercial Extension Developer** - A developer producing mass market extensions to make a living from it. | |
| * **Custom Extension Developer** A developer producing bespoke applications on customer request based on the CMS. |
| * **Extension Developer** - A developer producing mass market extensions to make a living from it. | ||
| * **???** A developer producing bespoke applications on customer request based on the CMS. | ||
| * **Integrator** - A site builder (integrator) combining existing solutions to match a customer's request. | ||
| * **Designer** - A template designer creating the look and feel of a site. |
There was a problem hiding this comment.
| * **Designer** - A template designer creating the look and feel of a site. | |
| * **Designer** - A visual designer creating the look and feel of a site. | |
| * **Template Developer** - A template developer that writes front-end code to create custom or mass-distributed templates. |
| These groups are further divided into different skill levels, which are used like adjectives. | ||
|
|
||
| * **newbie** - A new user with little or no experience. | ||
| * **novice** - A user with some experience. | ||
| * **intermediate** - A user with a good understanding of the CMS. | ||
| * **advanced** - A user with a deep understanding of the CMS. | ||
| * **expert** - A user with a deep understanding of the CMS and its internals. | ||
|
|
||
| Not all combinations of skill set and user group make sense. For example, a newbie extension developer does not exist. |
There was a problem hiding this comment.
I need to think on these some more. Someone could be an expert designer with a good understanding of how to design in a code-friendly way without knowing how the CMS works. Perhaps each persona could have two ranges available: one for skill level in that role, and one with familiarity level with Joomla as a CMS. Both are applicable.
| #### 2.1.1. Novice Extension Developer | ||
|
|
||
| This person has published one extension so far and wants to test how well the market works for them. If everything works | ||
| out, they want to offer further extensions to possibly make a living from it. | ||
|
|
There was a problem hiding this comment.
I don't think we necessarily need to define all the sub-personas; that will make it difficult to use and maintain. Defining typical ranges for each role for the expertise as well as familiarity with Joomla will be easier to understand. What do you think?
Personas are fundamentally intended to provide meaningful information for design decisions.
However, they can also have a broader use in an organisation to understand users and their challenges. Some of the original motivations for creating personas were to bring empathy for users into the design process, especially in organisations that are more technically driven. Product management, documentation, marketing, onboarding - these are all areas where personas can be useful. The key is to construct them in a way that is clear, simple and compelling.
Scratching our own itches, it happens to all of us again and again that we overlook where others have their pain points. We've been discussing how to solve this for a long time and have come to the conclusion that we finally need personas that represent our users.
The aim is to provide all stakeholders with a means of assessing the consequences of changes to the Joomla CMS on the various user groups.