HOWL
Case Summary
Problem
How can we improve the efficiency of work, and collaboration between members of a team to ensure optimal output of tasks and the completion of the team’s purpose while maintaining team relations?
Solution
By gathering information regarding each member to assign them to tasks which play to their strengths/interests, and providing the team with a methodology to follow which removes a strict order of project phases, but instead focuses on constantly evolving processes through rapid iteration.
Working through a semester of online school, like many others I found efficiency in teams to be difficult to arrange, especially working in different time zones on multiple parts of a project. It becomes difficult to get to know those you are working with, and successfully be able to understand each member’s strengths and weaknesses. When working on my VBA Team Project, I found that creating a task-assigning platform would be a great feature to have, however I wanted to build more on this. Looking to address the various problems which come with planning and individual member growth, I came up with the idea for HOWL.
Research
Before closing in on one idea or feature, I sought out to think of any and all problems which could possibly be addressed during the process. In order to do this, I created a How Might We Board where I listed every single possible feature or impact that this tool could have. The main theme I was brainstorming under was team management. During this process I brainstormed all the ideas I could think of, instead of focusing on the feasibility, or work required- I simply looked at “what are some problems”, and phrased them as a question which could be solved.
The How Might We Board is a very divergent process where no ideas are eliminated but instead considered to come up with deeper and more in depth solutions. In the end, the result is to narrow down to the top areas of opportunity and digging down to the root of the problem. Some of the questions I considered when coming up with the How Might We were:
What could go wrong?
What am I overlooking, simple processes such as closing/going back are often glossed over.
Who is this helping?
What emotions am I helping to avoid/bring out?
What are the problems each user ‘type’ is facing?
When considering an end-to-end process, what are the steps that a user would have to take?
Where is the destination to the experience?
After having a jumble of ideas all together, I put them in different groups. This allowed me to remove any redundancies and determine which concepts came up multiple times, as well as the depth of each group. By doing this I was planning out clear classes of concepts I wanted to address in the objective of the application. In doing so I noticed a couple overarching themes which were present across all the groups. I combined these smaller groups into supergroups which I displayed in an Affinity Map.
In the Affinity Map, I listed out the supergroups that were derived from the How Might We grouping, in order to find an overarching theme to address. Conducting thematic analysis allows me to come up with the following objective:
How can we improve the efficiency of work, and collaboration between members of a team to ensure optimal output of tasks and the completion of the team’s purpose while maintaining team relations?
Background Information
After determining one half of my main objective to be tacking efficiency of work and collaboration between team members, I looked into the progression of member relationships within a team. I explored Tuckman’s Stages of Development which illustrated a relationship between the efficiency in the project and the time that had passed, as a result of establishing team roles and personal development.
At the beginning of any team project comes Forming, where team members do not know what to do, how to do it, or why they are doing it.
Next comes Storming, a clearer understanding of the purpose is developed and a hierarchy is developed. However team members are reluctant to lean on each other, and collaborate. This results in a lack of coherence between team members, as individuals do not see their personal benefits.
The third stage is Norming, where members understand each other’s importance and the commonalities they share as a team. Members are willing to listen to each other and receive feedback. They are more willing to participate in team activities as they see the benefits it brings to them, and will contribute to the team.
After this is Performing; the teams performance is at its peak, there is an understood flow of decisions, and roles are interchangeable as required. The system is much more independent and requires little oversight.
The last stage is Adjourning, which occurs at the end of the project and simply provides a chance for members to reflect on the team’s progress, as well as their individual development.
Looking at the shape of the Tuckman Curve, it is similar to an empathy map where the user faces some sort of difficulty causing a drop in their emotions.
When searching for the root of the problem, eliminating this ‘drop’ is an important part of the objective. Since the user experience is the present consideration, it is important to ensure that all stages of the process are well-done, not simply the start and the finish, but the entire journey.
In order to minimize the impact of the storming stage on productivity and instead move onto norming and performing, it is important to have established information provided to the members right at the forming stage. This eliminates uncertainty, confusion, and overall disarray.
To gain an in-depth understanding of each team member, it is important to understand how they work, their strengths, and their weaknesses. Doing the Myers–Briggs Type Indicator Test will allow individuals to see their personal areas for improvement, and also allow other team members to ask for advice in areas they may be lacking in. Coupled with a list of goals, interests, and skills each member has, knowing each others MBTI type will allow for increased collaboration.
Addressing the second part of the objective, project preparedness through coherent planning, I decided to apply Agile concepts and frameworks within the project to allow for the use of sprints and iterative project changes being made.
Using the Agile framework of scrum I implemented product/sprint backlogs to keep track of work that still had to be completed as well as a sprint burndown for work that had already been completed. During each sprint the team would also have short meetings for updates at a set occurrence (daily, every other day, etc.) to keep everyone updated on the status of tasks. This ensures that changes do not come as a surprise and can be made quickly with little problems.
Using sprints is extremely beneficial as the entire project is planned at the start and allows for the production of deliverables throughout the process, instead of focusing simply on the end result.
The use of Kanban Boards and Gantt Charts are excellent visual aids in keeping up with how much work is left in the project, what has been completed, and any dependencies on project tasks. This is useful for both project leads and team members as they are both aware of the project’s current health.
After completing relevant research, I had an understanding of concepts I wanted to apply within the system needed to go back to the initial objective of the system and ensure that each part of the objective met with the needs of each potential user of the project.
To consider this, I created five different roles, for whom this project was directed at. These five roles have different responsibilities in any team, and will be completing different actions at each part of the project cycle. The project manager is in charge of the overall project, the sprint manager takes care of their respective sprint, team members work on all the sprints, the talent manager allocates members to teams based on their skills, and the resource manager adds and removes team members.
However since not every project would be able to allocate different individuals to each role, I ensured scalability of the tool by creating two user personas to use the project.
The first one was a businessperson, who would be managing multiple projects, but would have various other individuals who would be doing the actual work. This individual would also likely have an talent/resource manager on hand, who would be able to work with managing members.
The second persona created was of a university student who was using the project to collaborate with others across many teams. This was much different than the previous one as the student would often play all the roles in the team, including that of the team members. They would have to ensure that they can both manage multiple teams, and work in them.
The last part of the research stage is gathering all the information to list out the system requirements in the project. Doing this is extremely important as it allows for developers to understand the importance of each function, how it works, and what it does to improve the user experience.
The features marked as ‘High’ priority are those which directly connect to the objective of the platform. These contribute towards solving the immediate root of the problem, and are essential for success. Those marked as ‘Medium’ and ‘Low’ respectively are add-ons, and can be used as additions if resources are available. While not required for the success of the platform, it adds extra features which could be helpful in avoiding future problems.
Ideation
After deciding what features are to be included in the platform, I created a low fidelity wireframe which illustrated the basics of each major screen that was going to be present. I used colours to highlight the relationships between different screens, and indicated my flow of thought.
From the low-fidelity model I separated the actions the user could take into three groups, which would be decided at the login button. They could either create a profile, create a team, or sign in. While these screens have the potential of leading to each other, separating them allows for easier grouping of ideas.
In order to break down the attributes of each group and what commands the system would have to provide to the user for ease of use, I created a sitemap with an overview of all pages (blue), actions required (red), and system commands (green). Doing this allows for a clear outline of every page in the application and how it causes further actions down the line.
While through the sitemap, I laid out the flow of the pages, in the medium fidelity mockup I specified what components would be in which page, the input fields required, and the overall action items which would be present on each screen. This laid a basis for the prototype as it provides a basic understanding of the resources which need to be allocated towards each section, as well as advises the flow of the entire system. It is important to ensure intuitiveness for the user, and the mockup presents a check for this. While there are not any images or colour present, the overall ideas remain the same.
Prior to prototyping, the last aspect which needed to be considered was the typography, and fonts for the application itself. Since the focus group was for any type of team, the colour scheme would have to remain traditionally professional, leaning towards darker colours. However, since the theme was surrounding wolves and packs, I focused on purples and dark blues with light pink used for accentuating important information. The fonts used were Open Sans, Montserrat, PT Sans and Source Sans Pro in various sizes and highlights. The Serif fonts lent themselves to the professional theme throughout, and the use of Montserrat as a geometric sans typeface was used for titles and headings.
Prototyping
Feel free to click through the high-fidelity prototype of HOWL!
Evaluation
During this process, I expanded my knowledge on user research methods through exploring user personas for various roles and understood how to scale an application. I developed an understanding of web app prototyping and the differences that come from mobile development.
In a future iteration of the project, I would include more features such as presenting a Kanban Board and Gantt Chart for easier visualization, as well as the ability to integrate the system with other pre-existing platforms to be able to view the work completed within HOWL itself. Instead of navigating throughout various platform, doing this would allow for a more efficient user experience.
With regards to design improvements, I would like to work on a larger project, and implement more user testing to understand how to improve usability, as well as create my own vector art to fit with the overall theme.
