Visualization in Projects – User Roles and Personas

Agile methodologies suggest the use of user stories that are specific to a role. Personas are one way of representing these roles.

User Story

As Gloria J. Miller writes in “Going Agile – Project Management Practices” the format for user’s story should include a title and the information on the role of the user, the function they need, and the value they should derive from the function. The following is the type layout of the user stories.

As a <user persona> I want to <function; what they want to do>

so that I can <business value; why they want to do>.

A Role defines the characteristics of typical users for the system. It should be represented by a persona or an extreme character. A ‘persona’ is an imaginary representation of a specific user role or ideal customer, a sort of a “prototype”. Personas should be created based upon market and demographic research to ensure the persona represents the target audience or user. It is about focusing on the major needs of the most important user groups. One user can’t be everything to everyone.

A function describes the capability that the user requires. The function should finish with the completion of an activity and not an on-going activity. For example, “as a webmaster I want to manage a website” is something never ends. “As a webmaster, I want to add and delete web pages” is a task that can be checked as completed. Business value explains the importance of the function or the value it derives.

Persona Visualization

A persona visualization that can be used in projects is to create a poster or chart with the personas that are relevant for the system under discussion. The following visualization is an example used in a previous project.


Based on the article a few recommendations for visualization practices in projects, this visual aid fits the recommendations as follows:

  1. Specify your objective for visualization —
    • Deciding and scheduling who got what level/content of training;
    • Setting-up the role and security concept for the system;
    • Making design decisions about who could perform what tasks in the system.
  2. Make it action-oriented — used to facilitate discussions, meetings and design decisions
  3. Make it messy — N/A
  4. Make it specific to the situation — It was for a specific project.
  5. Use different dimensions — it uses different…
    • Position of the persona – was based on organization hierarchy and functional role
    • Role – system end-users’ role
    • Photos/Avatar – real people with whom details could be discussed
    • Text – describing activities that people would need to do with the system
  1. Make it interesting —

Overall, personas are crucial throughout the entire system or product development phase and should be real-life representation. They are vital to launching a useful and usable system or solution.

Project Visualization: Sankey Diagram of Project Effort – by Gloria J. Miller

Sankey diagram is a data visualization tool that can be used to visualize multidimensional data in different ways. Originally, they were used to visual the flow of resources such as energy or material. The important features of Sankey diagrams is that they represent the physical flow from a source to a target related of a unit of measure (e.g., functional unit or period of time) and that the magnitude of the flow is shown by the size of the link. (Lupton and Allwood, 2017)

For project management, Sankey diagrams can be used to show the flow of effort between such topics as companies, roles, and deliverables. The diagram is a Sankey diagram of actual effort for a technology implementation project. It shows how the total project effort is divided by different dimensions (i.e., company, role, deliverable, and capability) and how the effort flows between the different dimensions.

Based on the article a few recommendations for visualization practices in projects, this diagram fits the recommendations as follows:

    1. Specify your objective for visualization — Demonstrate how effort was spent within the project.
    2. Make it action-oriented  — Not action oriented in print; online each flow can be selected separately and the value of the flow is shown in a tool tip
    3. Make it messy — N/A
    4. Make it specific to the situation  this was the real history of the project.
    5. Use different dimensions — it uses different…
      1. colors, which show effort different sources and targets
      2. size, flow size is relative to amount of effort
      3. Dimensions: based on columns
        1. Company
        2. Project role
        3. Deliverable
        4. Capability
  • Make it interesting — visual way of evaluating project effort
How it was created

The diagram is based on the timecard entries for a specific project considering 1) the person, 2) the roles the people fulfilled, 3) their company. 4) hours worked, and 5) a comment associated with the time entry. The comments were analyzed and assigned to a deliverable and to a capability. The effort was summarized for a three-different source and target columns as follows.

List Source Target
1 Company Role
2 Role Deliverable
3 Deliverable Capability

All three summaries were put into one csv file and visualized using d3js Sankey java script. An example of the csv layout is as follows.The source code for java script at the following location.


Lupton, R. C. & Allwood, J. M. 2017. Hybrid Sankey diagrams: Visual analysis of multidimensional data for understanding resource use. Resources, Conservation and Recycling, 124, 141-151.

Project Visualization: Retrospective Review

Recently, we published a few recommendations for visualization practices in projects, so let us ‘visualize’ these recommendations through this board.

Any identifying objects for the project or the customer are removed from this version

The first time I saw this picture was in a project retrospective review meeting. I thought “are we playing a game?” It was actually a board in form of a snake, although not for playing, but rather for visualize what happened in the project we had just finished. It was used as a facilitation tool in a lessons-learned session with the core team members from the project. According to our recommendations from the last article:

  1. Specify your objective for visualization  This board was part of a retrospective review to discuss the project history, what happened, and what lessons we learned along the way.
  2. Make it action-oriented — In the review session, we used post-it’s to discuss what to change in the playing fields.
  3. Make it messy — Although it was printed, we were encouraged to change whatever we wanted.
  4. Make it specific to the situation — This was the real history of the project with the actual events that occurred.
  5. Use different dimensions — It uses different…
    • colours, which show effort estimates by week (e.g. black = less than 3 person/day in a week; green = 9-17 person/day in a week).
    • shapes, e.g. block is a week.
    • numbers, which are the weeks in the year (calendar)
    • symbols, which show activities when they occurred
      • inside the blocks = events (e.g. installed the server).
      • outside the blocks = risks (danger sign), holidays, collaboration.
  6. Make it interesting — this is obviously something subjective, but for me this board was catchy and it attracted attention.

The objective of the meeting was to discuss what went well, what went wrong (and why) and what could we have done better. The main idea here was still the act of discussing, communicating with each other as free as possible. This board was an efficient aid for visual communication that encouraged us to evaluate and measure in a comprehensive way.

You can find the template for the board at the following location: