We don't need more paperwork

The New Design Request Tool

Duration

3 weeks

The Scenario

The Promo Request is an online form that departments inside Health Initiative for Men (HIM) use to request design and promotional assets to the Communications department. These departments are Outreach, Health Promotions, and Office Management.

The process is: A team member has a request to make, they access the online form, fill up the fields, then submit it to the communications department. After that, the communications department will receive the form answers in their e-mails.

People from multiple departments have overall positive feedback about the Promo Request form. However, the way team members behave while using - or avoiding to use the form - shows that the Promo Request is not always the best option for them and sometimes reduces productivity.

The Problem

The following problem statements were gathered during the research phase of this project:

Team members from several departments see the tool as mere bureaucracy. There are way too many fields and depending on the type of project, lots of them are non-applicable or unnecessary.

Disregard the chaotic nature of their work. The form needs to be completed in one sit, which is not always possible. Also, some team members need to fill up the form from their phones due to travelling.

No sharability. Team members need approval from managers or inputs from other people in their team.

No estimations. It is just easier to talk directly with the designer. Also, the designer can provide turnaround times.

Challenge

How do we make the requesting projects task easier and faster as well as increase trust, engagement and collaboration between team members?

How requests are created?

I began the research process by having conversations with members from all teams involved with the promo request form. My goal was to understand where in their work process the current form fits, and what parts of the work process it is not covering.

By interviewing team members I also wanted to understand the request process itself step by step. Is there any preparation before? Do they face issues often? What happens after? What are the dynamics inside their teams and between different teams?

After talking with those people, I turn chaotic notes into an affinity diagram.

By grouping together these pieces of information, I was able to trace the requesting process and understand what parts of this process the Promo Request form was covering.

Who are the requesters?

So with a better understanding of the request process, I created personas based on the roles, needs and personalities of the people that I have interviewed. Here are a few examples:

Why Omar and Mark? I created these two personas two represent the typical dynamic spotted in most teams. Requests are mostly sent and managed by staff members like Omar, an event coordinator that navigates daily in a chaotic flow of projects. Mark, Omar's direct manager, does not have time to micro-manage all his staff's tasks but needs to keep track of the overall progress of projects by reviewing and approving requests before they are sent.

After defining those two key characters, I tested these personas in different scenarios to understand their behaviours and find opportunities.

By analyzing those scenarios, I found out that the collaboration through e-mails considerably slows down the request process and - if involving too many team members - is sensitive to miscommunication. Waiting times are also very stressful for both team members, Mark has trouble waiting to hear back from Omar, and Omar feels very stressed after submitting the request and not having any idea of how much time his request will take to get addressed.

Closing the Gaps

After hearing people and analysing the data, I tweaked the current request process to better fit the reality of the teams.

In the current request process, only the filling out and submission steps are being covered by the current form, other important steps (like review and wait) are not being addressed. Due to that, team members created their own ways to deal with this lack of support, they sketch and share requests drafts with each other by email in order to collaborate. The form is also not providing enough support during the waiting time, which is a big source of anxiety for most of the requesters since there is no prediction of turnaround time or timelines.

Collaboration is a very important step for team members so the review step must be covered by the new tool, and could run parallelly with the request creation. The create new request step can absorb the preparation step by offering a guided flow of questions, hints, recommendations, and save as a draft option. The wait step should also be addressed by the new tool in order to reduce team members anxiety.

That left me with a more concise and efficient request process (image below compares current request process VS ideal request process). The ideal process is shorter, with less back and forth between team members, and has more coverage from the tool.

How the new tool would work in this new process?

Ideally, the new tool would provide a way for team members to view requests - their own drafts, past sent requests, or even shared requests. So team members can be aware of what is happening within their teams and keep track of the requesting progress.

In addition, would support better the creation of a new request - providing different type of projects to pick, a guided flow of questions, and suggestions for deliverables.

And last, would aim to integrate the review step into the request creation work by allowing several users to share, edit together, approve, and comment on one request. The new proposed tool would also provide feedback about timeline estimations, response time, and follow up functions in order to reduce anxiety while requesters are waiting.

With that being said, I defined the 3 main pillars for the tool: View, Create, and Review.

The diagram above shows the 3 main actions (or pillars) of the tool and the arrows representing the user movement between those actions. Independent of where the user is, they should be able to move between those pillars freely.

And based on that the 3 main screens for the tool were sketched.

A new way to request - View

After some rounds of wireframing, prototyping and testing with the team members. The initial version of a new request web app started to get shaped.

The image below shows the new Promo Request Tool home screen populated with some requests after a few months of use. At this screen, requests are displayed as cards grouped in two different tabs (My request and Shared with me). The cards are ordered by the most recent and have two different states, Draft or Sent. Draft requests are requests that have not been sent yet and therefore can be edited by one or more team members.

The cards may also contain quick updates to keep team members aware of the progress of each request. If team members feel the need of checking the whole list of updates, they can access the Updates tab at the bottom-left corner of the screen.

Why mobile? I decided to have a mobile first approach to this tool based on experiences from HIM team members - especially the outreach department. Some of the most heavy users of this tool are people who have a very dynamic work routine and barely stay in the office. Outreach team members often have to attend to events, venues, meet community members, train volunteers, and etc. Commuting and breaks are usually the perfect time for these people to check their e-mails and request things to other departments, and their phone is their main tool to do so.

Initiating a request - Create

By tapping the Plus button on the home screen, the user initiates a new request. Creating a new request is a 7-step process where users will have to answer guiding questions regarding their project. The steps are Name and description, type of project, dates and deadlines, platforms for promotion, deliverables, references, and collaboration.

The guiding questions are context-sensitive and will change depending on the type of project that is being requested. However, the number of steps will always be the same.

The image below shows the creation screen. Note that, from step 2 forward, the questions are sensitive to the type of project that the user has chosen.

Communication is key! Throughout the questionnaire, multiple design elements were added to create a conversational tone aiming to increase the overall communication between teams. This also addresses some anxiety reported by team members when they feel confused when creating a request.

If you're really into the details. The diagram below shows the complete flow of questions when a request is being created. The design decisions made for this flow and what questions should be asked are result of an extensive research/conversation between me and team members.

Making sure you got it all - Review

After creating a request, it will be saved as a draft. A draft can be edited by one or more team members for as long as needed before being submitted to the communications department.

The image below shows a request review screen. The screen on the left is an example of a recently created request. At this screen, the requester can see a full summary of all the information inputted during the request creation and also a turnaround time estimation. From here, the request owner can go back to any of the questions to modify their answer and/or share this request with other team members.

The screen on the right is an example of a request that has received some collaborative work throughout some time. Team members can still edit the request since it is still a draft. Recent updates will be displayed at the top to keep all team members on the same page. You can also notice that the main commands at the bottom of the screen can change according to the role of the team member, some team members can be asked to approve requests before the owner sends them.

Collaboration

The collaborative aspect of the Request Tool is important. By not addressing collaboration, the old request form lost its perception of value and team members were seeing it as mere paperwork.

The following screens are dedicated to the collaboration features covered by the new Promo Request Tool.

The Updates tab can be accessed from the home screen, provides a timeline of updates regarding all projects. The Share tab can be accessed from the request review screen and allow users to share the request with other team members and chose their roles. The Comments tab also can be accessed from the request review screen and allows team members to communicate inside a request.

Outcomes

Teams from Health Initiative from Men don't see the request process as a mere bureaucracy anymore. During the test phases, team members showed enthusiasm and perceive the New Request Tool as a way to increase productivity and collaboration.