Scheduling Module

Context

We were tasked to create a new module for Blueprint, Daymon's flagship SaaS.

These requirements came up as a new client wanted to use Blueprint, but they were already using a software that allowed them to schedule tasks and see budgets, something that Blueprint could not do. This was a priority for them, and a deal breaker if we didn't had the feature, since using two applications would have been too cumbersome.

Background

Daymon is a giant in the retail world, that provides a full service on creating and managing products for retailers since1970. I have been working for the IT Team, based in Lisbon, since August 2018 as a Product Designer.

Currently, I am half the design team at Daymon.
The team has over 20 engineers and 10 QA's. I support design across every aspect of our business and am responsible for leading UX and UI across key parts of the application side of the platform.
I've grown tremendously in the last year, some key achievements of which I have listed below:
  • Implemented a design process. We work with Lean UX, and we came up with a process that has helped the team establish more structure to how we communicate between teams, and our work has allowed business to gain visibility across our upcoming sprints. We try to develop small portions of work, only focusing on what is essential (MVP).
  • Improved usability across projects. No usability tests were conducted before dev handoff before. Since we established a design team, we have been actively working towards conducting UX best practices, usability testing on all projects that we could, and managing to show the value of it to the business.
  • On every project, we establishing a design kit. We work with atomic design, making sure we do not produce extra work for the engineers unnecessarily. This has helped to maintain consistency in the look and feel across multiple projects.

The process

Our process at Daymon is based on the Double Diamond Theory and Lean UX process. We aim to incorporate the key phases of Discovery, Definition, Ideation and Implementation in all of our projects.

Understanding the problem

I conducted an interview with the Product Owner to uncover feedback. It was revealed that:
  • This was to be developed as fast as possible
  • This was to be a MVP using UI modules that Blueprint already had (since we used Atomic Design, this could be accomplished easily).
  • The new feature would be part of Blueprint

Product vision

We identified key business goals:
  • We want users to be able to have associated tasks
  • We want users to take action on these tasks, and adding time to it
  • We want managers to be able to assign tasks
  • We want managers to be able to track costs on projects

As a starting point, the design team did some market research on competitors to investigate the current offerings in the market and take inspiration from particular features that we liked about each app.

I then conducted a 15 minute sketching session to encourage each member of the team to draw out their vision of the solution.

Wireframing the solution

We started working on a wireframe so we could show the business our first ideas. The initial concept was to only create a small new feature inside Blueprint tasks - that already existed - and attribute a new start/ end task clock. This would be the faster and easiest way to implement a feature for knowing how much time a task took. We could also gather reports from it.

Validating the designs

We then conducted a new interview with users to see how close we were from the actual solution.

However, the response we got was that it was too simple. The problem was not the design, as it was the first idea of making it very quickly - The problem was that the users would need way more information to make this development valuable.

This meant that the business actually had to change their planning to include a lot more time and budget for this feature, since now they understood a simple change would not suffice here.

So we went back to user interviews, and from our collaboration, we determined the real value that could be achieved:

  • We rethought our personas This time, we went down our normal process, and we build personas. Turns out, we actually needed more flows than we initially thought. We needed to think about who was going to work on the task, who was going to assign the task, who were going to be creating the tasks.
  • We would need Teams Teams would be what would determine where each user would belong, and to which team lead.
  • We needed a timeline This was important to be able to visualize the information, as for example, 10.000 feet does. The timeline would help the team leads to know exactly who was available.

 

Wireframing a new solution

Going back to wireframes, we came up with a few new views: Time-tracking and Scheduling.

Time-tracking was only for Task Workers. The idea here being that the worker would only focus on his own tasks, his own times. Workers also need to be able to add their own personal tasks, so they can schedule time outs.

Scheduling was only for Managers. Managers needed to see everybody's time, and needed to be able to schedule and add tasks

Validation of new ideas

Although we did not had all the flow by now, we only went to validate these main two features.

Before going to users, we validated plans with engineer team first.

We conducted some usability testing sections with users, and realised we were on a much closer path to the solution.

Since we had validated some assumptions, we now could focus on the rest of the work.

 

Teams and Stage Owners

Every since we started, we were getting closer to a better idea of how the solution would turn out.

We focused now on how the teams would be added, managed and how a user would be assigned to that team.

Also, we needed to think about how a Stage Owner, which would be the person to actually build the task, would perform this. There was a lot of discussion with the whole team about this, since the Stage Owner was not a typical Project Manager, and therefore, there would be problems on just managing one stage of the project. After many back and forth discussions, we negotiated on how and where the new screens would live with the entire team, and with the agreement of users.

Some examples below.

image

Developing the designs

We build high fidelity mockups, and documented the whole process on a wiki page on Azure Dev Ops, to help everyone understand what needs to be developed, and why.

The final designs include a much more detailed version of the scheduling, with features from showing if a task is over budget, late, or OK, and also a way to see if a worker has too many tasks in a given day.

The designs were approved by the users, stakeholders and dev team before getting into development.

 

Design Assets and Documentation/ Follow ups

As we work on the designs, we have the need to explain to a lot of different people the flow that we are taking for different features.

As such, we develop along side the designs, UX documentation that normally is stored with the rest of product assets on Azure Dev ops.

We call it a wiki, and it is totally built by the design team, and we fill it with screenshots, explanations of flows, gifs to clearly explain some features, etc.

The design team stays connected with developers since problems tend to arrive during sprints, and we work alongside each other to solve, manage expectations, and get to solutions quickly.

An example of the wiki below.

I worked very closely with the Front End team to spec out any missing interactions that were not covered in the high fidelity mockups. I conducted a UX review of each front-end ticket that was implemented to ensure it was aligned with the designs before it went live.

Results and takeaways

Working in this development was a steep learning curve. It was an eye-opening experience that taught me a lot about being lean and knowing when and where to focus your energy and efforts. The fact that the requirements were not well thought at first got us into loosing momentum, but it also helped me understand how to conduct better interviews.

Description

  • Daymon

  • 2021

The goal was to develop a new feature that would make the integration of a new client easier.