Portfolio

Timesheet Tool – UX case study

Work environment

• Stakeholders: Internal (company employees)
• Tools: Google Suite, Figma & Figjam, Paper (sketching)
• Design: From ground up, pre-existing Design System
• Devices: Web (Cloud, Browser)

Premises

• Information received: Environment, partial UX Research, No Workshops
• Objective: “Provide an early proposition/solution for a set of challenges and needs, while outlining the process followed”

Assumptions

• Principles followed/consulted: Hick’s Law, Endowment effect, Analysis Paralysis, Cognitive Load; Functional Fixedness, False Consensus; Motivation Principles; Nielsen Norman Usability Heuristics and WCAG (for ideation and design stages)
• Hand-off ETA: Dynamic according to testing, re-iteration and environment; Minimum of 4 weeks.

Cooperation

• Review with stakeholders: Regular, more frequent e.g. after creation of early design ideas or first mock-ups
• Contact with engineers: At Research, Ideation and Prototyping/Handing off stages
• Contact with other UX Designer: During Research, Define and Ideation stages (if possible via brainstorming sessions or feedback sessions)

Result

• Handed Assets: User Personas, User Stories, Hypothesis statement, User Flow, Low-Fi Wireframes

I have recently completed a case study for a leader in the IT industry. The goal of the study was to determine the potential approach, risks and appropriate processes to follow in order to obtain the best solution.

I was given a set of findings: among these some challenges, pain points, user and business needs.

Pain Points

Despite the existing workflow and regularly carried time-estimates, a vast number of employees have difficulty completing their projects in time and meet previously established deadlines.

The current workflow involves the use of multiple tools outside of their scope. This requires time-consuming actions and a lot of manual calculations.

Projects divided in sprints are often assigned an inaccurate amount of time to be completed.

Challenges

The future users of the tool work mostly in Agile and are often not comfortable with strict time tracking and planning. Some of them however are used to tracking and reporting their work from previous work experience.

Some employees are moved from one project to another according to business needs.

Additionally different teams work on different types of projects, e.g. internal or external projects, they may therefore need to be divided differently (hourly, per project, ecc) depending on the client.

Needs

The business needs to track employees progress to better manage clients expectations. Moreover other departments such as HR and Finance need the tool to integrate with existing systems in order to keep billing and attendances records up to date.

Stakeholders require a better reporting workflow to help distribute and re-organize work where necessary.

The Process

Before I identify the best framework to follow, I focus on understanding what are the business issues, objectives and motivation behind the project. I gather information on research budgets and time frames.

Understanding the premises of a projects is a core steps to choose the right course to start an entire product life-cycle. To do it in the most accurate way I ask questions, analyse data, organise workshops with stakeholders and/or clients.

Once I have a good overview of the background, motivation and business environment, I can choose the most fitting framework to follow.

Due to the nature and complexity that comes with designing and introducing a completely new tool, I decided to follow the 5 stages Design Thinking mixed with Agile UX: Empathize, Define, Ideate, Prototype, Test – with Agile’s constant iterations and regular user feedback to move the design of a complex new tool in the right direction. For the assigned challenge I have carried the first 4 stages of the framework, only outlining the last two stages.

I considered various approaches: Double Diamond only, User Centred Design, Habit Building framework, ecc. While Double Diamond is a form of Design Thinking, I opted for the latter due to its focus on research and empathy. User Centred Design on the other hand could potentially not focus enough on business needs.

Throughout the entire process I keep in mind psychological principles and Heuristics relevant to each stage.

During this Stage I usually organize the Research according to time and budget: whether to opt for quantitative and/or qualitative, defining the criteria to recruit users, preparing research goals, setting and most importantly questions.

As in this project I was not responsible for attending to the above, I posed a few question to the UX Researchers to expand on the provided findings and best empathize with users:

• Do we know why employees are failing to meet deadlines? What is the correlation identified between this pain point and the workflow or tools used?
• Has the research found any differences between employees that complete work in time and those who do not? Does motivation play any role in this pain point or is it purely organizational?

• What is the current workflow used to track progress and work in general?
• What are the tools employees use right now? What tools did the employee used during previous experiences?

• How do employees usually categorize or divide their work? Beside hourly, daily and per project (external/internal), do employees and management use other values?
• What are the metrics used to evaluate work and track progress? What values does management need to keep an eye on?

The information I received back confirmed some of my assumptions:

1. The cause of failing deadlines was found to be organizational, likely due to lack of a single consistent tool helping schedule tasks and keep track of progress/due dates and absences.
2. No clear differences (other than occasional paper-planning) were identified yet between users failing deadlines and those completing projects in time more often.
3. The currently used workflow requires the use of Google Calendar, Gmail and Slack messages for different task such as setting reminders and communicating progress via email and chat messages. Tools such as Jira to assign tickets or manage sprints are not currently in use. Timesheet tools used by a portion of the interviewed users were either internal or aligned with the general trend in the sector.
4. Management categorizes work according to billing: hourly, daily, per project; external, internal – and set deadlines accordingly.
5. Metrics mentioned by management and employees focused around time spent on different types of project and time spent waiting for an answers (delegating).

Additionally, thanks to the above questions, new findings were provided: users expressed their frustration with the scattering of information resulting from using multiple tools and the consequent need for strict and time-consuming self-organization.

During this stage I also carried a quick research on the timesheet tools mentioned by user in past experiences in order to to be used later as ground for potential natural mapping.

Given I could not observe the body language of the users and participate directly in the Research, I decided to stick with tools that allow me to represent the findings while leaving more room for edge cases and avoiding falling for emotional biases.

From the findings and assumptions of the Research stage, I have drafted two Users Personas and User Stories to have a better idea of the circumstances the design should adapt to, and a practical reminder of the needs and feelings of target users.

While putting these together I usually evaluate findings against a pool of questions to ensure I understand underlying pain points and eliminate cognitive biases: e.g. Are there any pain points hidden behind the findings (Do I think users have successfully verbalized their needs)? Have I noted down users’ emotions and reactions? Am I aware of the environment influencing their answers? If possible, I like to get another perspective on the findings and reach out for other designers’ feedback via email sessions or even workshops.

I have then moved to writing Problem Statements, to define more clearly the issues users have been facing so far…

…and a Hypothesis Statement, to define the desired outcome of the design.

As a result of the framework chosen for this design, during this stage my goal was to gather as many ideas as possible, evaluate them against a set of questions aimed to keep all ideas within the project scope, prioritize the single solutions in order of relevance and impact (using for example the RICE score) and eliminate unnecessary features.

Questions I ask myself while ideating may be:

● What are the issues highlighted by the Define stage my design should resolve?
● Which of the issues highlighted by the previous stage should the tool resolve first? What are the top priorities?
● What are the values teams and management need to monitor beside deadlines?
● How should the tool integrate with data from other tools (provided such data can be extrapolated
from those tools)?
● What functions should be implemented to make the tool useful and valuable?
● What is the natural mapping that may occur for users who have experience with similar tools? What
are the design patterns used in those tools?
● How should the tool deal with the differences between the projects (external and internal) and their
duration(daily, monthly, ad hoc, ecc)?
● How to accommodate the main types of target users, self organized, precise users and more
spontaneous and agile users without creating new issues or roadblocks?

The main ideas I considered ranged from live status tracker, to calendar planner, to task dashboard, with features such as status change, task customization and project progress.

Out of the three main options, I decided to prioritize the deadlines-failing issues and the environment the tool should fit well in.

I took forward the idea of the calendar based format as the potential benefits addressed the most prominent issues from the research stage. This design idea had the highest RICE score and appeared to be the best compromise between a simple and straightforward design, allowing at the same time the integration (also at later stages) of additional features.

Sketching

Depending on the project’s nature and base, my process at this stage and the order in which I create paper wireframes, sketches, IA and User Flow varies. If a project is complex or the ideas many, I may move rapidly between the visual representations and re-iterate them.

In this case I have sketched few wireframes already during the ideation stage, this was prompted by the issues I prioritized and to ensure the ideas I was considering could be easily translated into an effective layout.

In my low-fi wireframes I designed the default screen to be accompanied by a project overview drop down card on the right side and a drop up notification menu on the bottom right: for delegation requests, out of office notices, approaching deadlines or set reminders. Following natural mapping from other popular timesheet tools, I placed on the left side a menu for general settings, overview of colleagues calendars (if made visible to the user), and functions to be potentially added at a later stage.

For Senior management I decided add a third tab with a simple overview of users ongoing and completed work, with a toggle on/off for various teams and users.

I also created a User Flow (below) to represent the process for the core actions: add/edit task, delegate, mark as ongoing and complete.

Once the first ideas have been reviewed by the stakeholders, I usually move to the next stage of designing and prototyping.

During this stage it is particularly important to design according to important design heuristics, for example Nielson Norman Group Usability Heuristics and WCAG, while keeping in mind relevant psychological biases, behaviours and social patterns.

In the previous stage I have weighed the pros and cons of different ideas and have settled for a base from which to start working on the design. From this stage on I expect more testing and re-iteration, as per Agile Framework. Each page I would start designing, from low-fi mock-ups to high-fi designs and interactive prototypes, I would expect a pool of users to test (via e.g. usability and first click testing) and stakeholders to review (wherever needed). Based on the results obtained I would adapt the design into new iterations until each page is ready.

The process I chose to follow for this project focuses on delivering a minimum viable product which can then be expanded with already designed features or ideas answering new findings and feedback from post-launch monitoring

After designing detailed mock-ups and ensuring all elements are consistent with Design System and Company used patterns, I would handle the ready screens to engineers for whom I remain available throughout the entire process. I expect technical hiccups (e.g. data extrapolations constraints caused by other tools) and consequent reiterations but I also remain available for any clarification.

As this stage is crucial to translate ideas and images into useful experiences, I ensure my design and materials are clear, detailed and adapted to technical requirements.

While one delivered design is being developed, I usually work on other screens, repeating the relevant stages all over again.

Process Summary

Stages 1 – 3 key tasks

• Understanding Business needs and environment, Research issues and user needs
• Defining Findings, developing statements and empathy tools
• Ideating possible solutions, evaluating their usability and impact, removing unnecessary elements, brainstorming early visual representations of ideas

Stages 4 – 5 expectations

• Design: Creation of Hi-Fi Wireframes and mock-ups in Figma with clickable prototypes (for tests and for development) basing on the existing Design System
• Heuristics/Principles: NNH, WCAG, RICE score,
• Re-Iteration: As per Agile UX Framework, development of a MVP with constant testing and re-iteration
• Testing: Usability, First-click and/or 5 second testing done by a diverse pool of users on live prototypes,
• Contact with Engineers: Regular reviews after creation of first mock-ups to re-evaluate viability of designs (time, budget, licenses, ecc); Ad Hoc/On Request after creation of prototypes for development