top of page

---- Project Planner ----

ORTEC

A (hybrid) mobile app where e.g. hospital staff can view and schedule everything related to their planning.

My role

  • UX design

  • User research

  • Usability testing

  • UX and design research

UX products

  • Research

  • Job stories

  • Taskflows/ wireflows

  • Wireframes

  • Prototypes

  • Workshops

  • User tests

  • Digital writings

  • ...much more

Planner.png

*Disclaimer: due to the non-disclosure agreement with the company, I am limited in the work and information I can share. That is why I have given this project a fictional name and only show some sketches.

About the project

This is a project I worked on for ORTEC. Project Planner is a hybrid app based on an already existing native app and an existing web app. This app allows the user access and plan their schedule from their phone.

 

This hybrid app is meant for clients who already use the native and web app. Clients could differ from big to smaller sized companies. Examples of clients could be hospitals, airports or retail stores, we have a global audience.

 

Our goal is to improve the native app, because this is very outdated and not user friendly at all. Some functionalities don’t work or are not even available. The web app is up to date with design and functionality, so we want to match the hybrid app to this. It should have a similar look and feel, since it’s meant for the same user.

  • The user is familiar with the native and web app, which means that they have certain expectations. Introducing new patterns and flows could become a challenge and take away usability.

  • Limited technical possibilities since the app is going to be based on already existing apps.

  • Could be a challenge to introduce new functionalities.

Challenges

Intro project2.png

Process

This it the same process as described in Project Calculations.

Planning/briefing

Research

Design concepts

Feasibility check (tech)& User test

Final tasks & Development

  • Plan what UX is going to do during the sprint. I work a couple sprints ahead of the team.

  • Refine high level job stories.

  • Talk to the relevant stakeholders for this step.

  • Plan and make an estimation how much time and work the tasks will take.

  • Discussions and interviews with the Product owner (PO) for more context and functional requirements.

  • Talk to the lead developer to discuss technical boundaries, so this can be kept in mind while designing.

  • Define and refine scenario's, create persona's.

  • User research, user interviews, observations, survey's.

  • High level (task) flows.

  • Process findings of all the research mentioned above.

  • Brainstorm sessions.

  • Make sketches.

  • Design wireflows and wireframes.

  • Verify with relevant stakeholders.

  • User test if possible, if so, make a (interactive) prototype.

  • Validate with lead developer if the designs and flows (=UX/UI) is technically feasible. 

  • Discuss alternatives if there are challenges or difficulties.

  • Discuss how to handle everything that is not feasible, either we do this in later sprint or the UX/UI needs to be adjusted. 

  • Prepare user/usability test sessions, write the test scenario and questions to ask the user.

  • Conduct and process the user/usability test result.

  • Discuss the findings with the relevant stakeholders.

  • Finalize the digital writings.

  • Finalize the UX/UI.

  • Kick-off the UX/UI with the rest of the team by giving a demo.

  • During development the team always has some questions regarding UX. We solve this on the spot, or within a fast time frame, so the sprint goals can still be met. 

  • Always keep up-to-date with what the developers are doing to tackle issues of they occur.

  • Issues that cannot be resolved right now should be noted down for the future.

For each project is feedback a constant thing for each step in the process. At evert step in the process I collect feedback from the relevant stakeholders, be it the business stakeholders or the users, but could also be developers or architects. If I notice that we are not aligned and cannot come to common ground, I go back to the drawing board and think of new concepts that fit better with the needs and expectations.

 

For this project it was important to work fast. That’s why I made very high level designs and showed this to the PO or developers and if it was not feasible, I could go back without having wasted too much time on the designs. When the flows, and most of the UX, is finalized, working on the visuals could get started. 

My role

UX designer and User researcher

​

The team has an Agile way of working, we work with SCRUM. The project was already ongoing for a couple of weeks when I joined. Together with the UI designer and another UX designer we formed a smaller team within the team, and we were responsible for everything related to UX/UI within this project. I work closely with the Product owner (PO), but because it is an improvement of the native app different stakeholders decide what the business/client needs. Which job stories we pick up is based on this, however, there is some room for prioritization since I work at least 2 sprints ahead of the team. So I also have a say in what is important to pick up right away and what can wait. After this is decided, I start the UX work and have regular contact with the PO, stakeholders and developers. I keep collecting feedback and iterating until goals are met. Which means technical feasibility, business goals of ORTEC, business goals of the client but most importantly user needs and usability. 

 

Important part of my role is to focus on how to improve the existing functionalities. I have to research what is best, for this I have conducted user research and several user/usability tests.

  • Design system of ORTEC

  • UX and design research

  • Wireframes and flows

  • Usability testing

  • UX/UI best practices

  • Taskflows

  • User research

  • Interviews with stakeholders

  • Test scenario's

  • User interviews

  • Personas

  • Write digital text and materials

  • ...much more!

Tools and methods

Project P2.png

Findings and solutions

The job stories we were going to start with were decided when I started the project. I knew the goal was to improve the native app, but I only looked into the functionality and not so much the look and feel. I had the advantage of a fresh point of view, I was less influenced and biased of what was and what could be because of this.

The first job stories were focused on viewing the schedule and the details that belong to each shift. We made designs that had the look and feel of the web app. However, a web app and a mobile app both function differently, we had to take this into account as well. The web app has a big calendar with all the info in it, that will not work on a phone. Less space for information and it should still be legible.

 

For our first designs we made a list schedule and a smaller calendar on top which they can open and close whenever they want. On the day details page we show no calendar, instead there is one at the on bottom, where we showed 5 days. The user could scroll back to past days, but also forward. We tested this with users and turns out that we complicated the day details too much. They like simple and straight forward things, what they are use to came up many times.

With this information we went back to the drawing board and came up with simplified designs.

These are the high level designs we made for the flow. I cannot share any of the original visuals, only the sketches we made very early on in the process. The sole purpose is to visualize the flow. 

Home.png
Day details leave.png
Dat details planned 2.png
Sched.png
Day details planned.png
Day details expand.png

You can see that we simplified the designs. The user opens the app and lands on the schedule page, their upcoming shifts are showed on this page and it also serves purpose as the home page, because being able to view their schedule was the most important job story. They can see the schedule in a list view, where they can see the days that they’re working. The days with special occasions, like holidays or leave, are marked. For an overview of the whole month, we have a calendar on top. The user can scroll through this calendar and it has the same marks as the list view. The user can click on a day and the list view navigates to this day.

The shifts are visualized as small chips, the size represents the length.

The user can click on a day in the list view and will be navigated to the day details. Here they can find shift details of each shift the user has that day, because there could be multiple. They can also find their team schedule and other relevant notes.

I user tested this new flow and it was so much more clear for the users. The flow, look and feel were familiar to the user, it reminded them of the web app but with improvements, they’ve said so themselves and that was a nice confirmation.

 

Expectations of the user are met without taking away the usability, technical feasibility, Jakob’s law, Miller’s law, Fitt’s law

One of the other job stories was adding leave requests. In this wireflow I describe how the user could edit or delete his pending leave request.  

Flow example.png
bottom of page