MDO Scheduler redesign
Introduction: Redesigning the backbone of a medical practice
The Medondo Scheduler is an integral component of the Medondo Coordinator Suite. It manages the appointment process, sends out reminders, and oversees room and doctor scheduling. The efficiency of this system is directly tied to the operational success of a medical practice.
Initial release
In late 2019, the Scheduler 1.0 was introduced as a minimum viable product (MVP). Its purpose was to establish a foundational tool within the Medondo suite.
As a result, a lot of needed functionalities were not included and some parts seemed to have been developed without including any designers in the process.
The redesign challenge
Our feedback collection in 2020 revealed significant gaps in Scheduler 1.0. The rapid development timeline had led to a lack of comprehensive research, causing the omission of some necessary features. Users reported both functional and design inconsistencies, suggesting that the development may not have adequately involved design expertise.
These insights, coupled with the introduction of the new Medondo Design System, made it clear that a redesign was imperative. Beyond mere cosmetic improvements, the redesign process for Scheduler 2.0 was seen as an opportunity to enhance the application's functionality.
We not only addressed the identified gaps but went a step further by introducing a range of new features. These features aim to ensure that Scheduler 2.0 feels like a genuine evolution, providing a robust user experience and cementing its place as a true "version 2."
My role in the project
I was one of 4 completely remote working interface designers on the project. We worked together with 10+ Devs and 1 PM. My work on this project can be split up into:
Analysis and concepting
I created an updated concept of the application, its user flows and features on the base of existing feedback and understandings from the old Scheduler together with the head of design from Medondo.
Designing components and layouting
I was responsible to coordinate 3 designers (myself included) in the process of the screendesign process, which in the case meant getting from wireframes over design system based and newly added components to responsive and visually appealing layouts, that can be documented and shipped to the devs. Also I worked on documenting our added components and changes to existing components in the design system, as well as in documentation
Analysis and research
Lack of quantitative data
Because there was only little use of analytics tools due to previous internal focus on speed of shipping the product, we were left with a very little base to start with a quantitative analysis. So the only implemented tool has been Google Analytics to track the user number, but that was pretty much it. No heat maps, no click flow analysis, no session recordings. Without the existence of this data, upgrading a product can in the worst case scenario only be done on the base of hypothesis.
Fortunately, part of Medondo's business model is having a strong connection to the doctors and the practices – and therefore with the users. This proved to be one of the smartest partnerships I saw to this day. So even though we weren't able to analyze click flows and user behavior through software, we had the connection to a huge source of immense amounts of qualitative data.
Workshops and stakeholder interviews
We started to do workshops with the "Medondo Innovation Club" – a group of practice owners that were on board of the whole Medondo project since the early beta phase or practices that are especially interested in the development of the application. Early adopter practices to give it a more commonly used term.
This led on the one hand to more feature requests and a lot of insights from the perspective of the owners, but wasn't really helping to find flaws in the actual Scheduler application. Even though, it was important for us to understand the impact of the software on the business from a birds-eye.
The main takeaways for us were, that especially two things occurred since the usage of the Scheduler 1.0 in the practices: the users took more time to organize the practice – but in a better organized way than before (which was sometimes other software, but sometimes even pen and paper). The second and quite grave point was, that the user happiness wasn't always high when using the tool.
This proved one thing to us: the idea and basic concepts behind the Scheduler were great, but lacks in usability and features still left a lot of potential to improve.
Qualitative data
The power users of the application we were going to contact in the next steps were the people that use the Scheduler to actually organize the practice – which are mainly the assistants. These people do pretty much everything that is not the work of the doctors. For us, this was the primary source of analysis and feedback.
Together with the help of the practice owners' from the innovation club, we have been able to organize user interviews and multiple visits in an actual practice to do live research in the field. Moreover Medondo had an implemented feedback button, which was able to gather quite a lot of feedback as well.
With all these methods combined we ended up having a pretty solid base of data which we could combine to analyze where the biggest pain points in different areas of the application lay.
.webp)
Feedback button – in-app feedback
Through an implemented feedback button we were also able to gain feedback directly attached to an automatically taken screenshot – that was mostly super constructive. Even though there has been a quite big variety of feedback, this source helped a lot to broaden our horizon towards other practices.
The insights we got here eventually ended up being similar to the learnings we were about to make in the field.
Excursion to the practice – UX in the field
Through the strong connection Medondo has through the innovation club and the fact that the Covid cases were extremely low in the summer, we have been able to visit 2 practices and watch the behavior of our users while using the application live within their day-to-day work situations.
We could place us behind the assistants' desk of the reception – looking kind of like the new interns – and literally see which user clicked where when and what triggered their behavior. A once in a lifetime user story investigation. Also we have been able to ask questions regarding their interactions in the software when there was no patient around. Moreover, we have been able to see where in the practice which device was used for which use case – which also added a lot of insight for other projects I've been involved in.
We took notes of how assumed user stories looked in a real life scenario and how actual user behavior differed from our theories and older research. Also we collected critical points in which e.g. less experienced users had to ask the "pros" of the practice to continue using the UI – we didn't help at all (sorry to everybody in hindsight, but helping you in that very moment kind of ruins our work).
With this experience I realized that focusing on the context of the user while, why and when he/ she is using the application, is one of the most important parameters when designing a good product experience. Also to stay humble – you're never even close to understand what users really need without asking or researching on them.
Usability Interviews
We gathered a lot of feedback from structured interviews with the users. We gathered this feedback in the practice excursion we did, as well as in multiple online interviews. After that, we ordered our results into different categories.
Especially interesting was to see which steps the users took within the software to get their work done. These were our so to say handmade session recordings.
Getting the prioritization right
In the end, we had to come up with a method to prioritize our main results to see which changes were most needed to provide the biggest possible improvements to the User Experience – since our work hours as well as the dev capacities were limited due to other projects. Therefore, we created a BCG-Matrix in which we compared the gravity of the different issues / negative impact on the user's work flow meaning user experience with the frequency of feedback/ occurrence of a problem.
This order helped us to see where the focus of our redesign efforts should be. Also, with this graph in mind, we kind of already had a feature update backlog we could sync with the PM.
Concepting
UX architecture and wireframing
With all that the gained data, knowledge and updated user stories, we started to create a basic UX architecture around the new Scheduler's main interactions of the application. After that, we did a deep dive in every main interaction field (divided by the colors), to map our user stories and to work on more detailed concepts. We then used this as a base to see which were the main views and main components we had to wireframe in mind.
With the more detailed concepts of everything, we were able to start into the wireframing. We had a lot of back and fourths between our concepts and the wireframes, but rarely had to change the UX architecture. We this form of creative process, we went from bullet points to profound wireframes that could already explain every interaction of the software in detail.
Because every designer took over different parts of the application within the wireframing process, our screens also contained thoughts and information we wanted to share or save. This made the wireframes look way sketchier, but turned out to enable a way easier collaboration for us in creating the wireframes and in the end the screendesign. Also, it was the only possibility to capture the complexity of the application, since a few of the interactions were custom and did not follow any UX design standard, because there were no standards or best practices for the interface we had to build.
A key learning for me in this process was, to keep transparency of used information within the creation of wireframes and screens high. It's more important that your team understands you, than to produce the most visual aesthetic wireframes on the planet. When everyone follows this mindset the whole concept behind an application gets much clearer to a point where each designer can be replaced in case of an emergency (we had this case).
For us this worked out quite well, because we were able to share the workload equally in our design team and the whole concept was clear to everyone. This enabled us to focus on achieving an aesthetic yet functional design output, without questions about concepts coming up way too late in the process. Also, the logic between wireframe and design didn't change too much – which proved us than our concepting phase worked.
Example: Fixing Appointment Details
I want to show one practical example of a one of the changes we did in the new Scheduler 2.0. One key factor for a lot of people was the user experience of interacting with the appointment details. This is one of the core interactions within a practice of course.
Problem 1: lack of information
The user wanted to be able to access more details and other information from this view. There are a lot of things connected to an – things like the patient, the durations the invoicing and a lot more...
Problem 2: no multitasking
Often enough, while working with one appointment in the software (e.g. editing) someone calls or enters the practice to ask something. There is always so much stuff happening in the life of an assistant. They barely have 5 continuous minutes without any patient interaction.
Solution
We tackled these two problems with switching from the appointment details being a static dialog to a more dynamic sidepanel that appears in the right side of the screen and represents one selected appointment. On left click on other appointments, the sidepanel switches to the newly selected item. While having the details on the right side the user still is able to interact with the canvas and the rest of the interface without closing the appointment or searching it again afterwards. Other appointments could be even quickly edited with the new right click feature. The possibilities of multitasking grew a lot through these changes.
Through this method, we were also able to fit more information and interaction possibilities into one appointment without overwhelming the user with a huge dialog. We achieved this with a tab bar on top of the sidepanel and quick interaction bar at the bottom. Through these we easily had 10x more options without more clicks or having a more overwhelming interface.
Problem 3: Speed of possible interaction with an appointment
The users often got called to cancel an appointment and experienced that the workflow of for example moving or deleting an appointment felt way too slow.
Solution
To solve this, we came up with a custom right click functionality on appointment cards as well as on the canvas. Custom right clicks get more and more common in a lot of web applications, so we felt safe to use even though our users could not considered to the classic digital native. Through this change users are now enabled to do every interaction they want with the appointment data object without having more than 2 clicks or mouse travel time since the right click dropdown appears (obviously) right next to the mouse courser.
Mock-Up User Testing
After being finished with the wireframe and therefore with our redesign concept, we felt ready to reach out to our users for another user test. We created Mock-Ups out of the most important and grave changes we applied to the application in the new "look".
The problem that of course always occurs when testing mock-ups, is that the abstractness and the limited functionality of a prototype can hardly compare to a finished application that you use in a day to day scenario. So we made sure to ask the same users that already gave us feedback in the analysis phase to participate. Through this, we made sure that enough knowledge exists, to imagine how the changes we implemented and now showed affected the application – and if this was good or bad.
Our results were overwhelmingly positive. Also with further question we made sure, that the before broken workflows and UX flaws now would remain solved.
.webp)
Component Design
Splitting up an interface into it's components
As base for our designs we used the newly created Medondo Design System. Before this the whole application was based around the Material 2.0 framework, which ended being too limited in various use cases. The design system was pretty much based on the atomic design approach. That means that every element in the application is always deconstruct-able into smaller parts down to a single button or a single input field which are the atoms.
Although the design system was relatively new and work in progress – as it's always the case with a design system – we already had a solid base of elements to start with the designs. On the one hand now we had to use elements that already existed in the design system if it was possible. On the hand we had to create new elements specifically for the Scheduler, make them part of the design system and make sure that it would be usable for other applications later.
At this point I took over the team lead. In terms of the actual work process I had to make sure that:
- we didn't design elements twice
- everyone knew what to do at every point and with whom to work in which file
- that every created component fits into the design system and can be extended / modified and reused in other applications
- that every component we had or that had to be created fits the visual aesthetics as well as the common usage and behaviour of other frameworks like Apple HID or Material Design23590
I did that by dividing the created wireframes into little pieces down to a component level to compare it than with the existing components and to see which existing elements could be used and which needed to be newly created. After identifying every component I divided our components into
- Usage of existing component possible
- New variant of an existing component has to be created
- New requirements for a variant of an existing component need to be implemented in DS
- New component has to be created
One example for a new element we needed was the asset of the main calendar view, which would be build out of different atoms and molecules. I sketched the process of how I divided the screens in the main view areas, to make sure the guidelines of responsiveness and layouting from the design system could be kept while extracting components:
Through ongoing iterations and coworking sessions within the team throughout the whole design process – especially in the documentation – we made sure, that everything fits the interface and the the information and knowledge transparency kept being as high as possible.
Advantages of a design system in the dev hand-off
I our workflow we wanted to secure a fast developed through starting the first dev sprints while we were still in the process of designing. So while building our new components like the Scheduler Appointment card, we had to enable the developers to produce finished and high quality code for a shipable application. To secure this possibility, we already documented every created component in the process of creating it. Through this workflow we could hand off single components without the necessity of handing of the whole layout / the whole prototype. This increased the developer productivity and lowered the project duration immensely.
Likewise with this workflow we tried to keep the knowledge transparency in between the teams of design and development high. This led to a lot of benefits, because we were able to ask and answer questions of the devs before problems would occur later on in the process. In some cases for example we iterated on certain components to implement specific changes in the design or functionality to avoid possible catastrophes in the development (or better speaking in the planning poker) later on – and reduced the dev time in some components by 50%.
Layouting
Collaborative layouting and screen design
After finishing the components we started with the actual responsive layout process. Everyone of our team got to work on different parts of the layout – I for example created the whole day view and every interaction of it while my teammate Elena created the whole week view. With our collaborative approach in the phases before and a few coworking sessions in between to exchange thoughts and ideas, we have been able to build 30+ screens each of us containing the core functionality of the application nearly completely separated from each other. The screens used even partly the exact same components and logic.
A learning I took here is, that a collaborative design approach is not a buzzword, but a philosophy which every product team can and should apply. Especially in a company whose success depends on the user experience within the context of a digital product. Therefore working with collaborative Tools like Figma, FigJam or Miro is an absolute essential not in the future but today – even if you don't work remotely.
Modular design approach
With the strategy of dividing the whole layout into these different structures, we were able to build a modular layout so that later in the process we would be able to easily add components or change parts of the whole UI for different use case / scenarios or new feature requests.
This made also the dev hand-off easier, as not only us but also the devs are able to customise a screen in any aspect they want. With this modular approach we achieved to lower the dependency from the devs to us even when we would start to ship updates and new features to the application.
With the whole modular and interchangeable approach, we tried to achieve a possible extension of the application into an adaptive design approach like Material 3.0 in the future. In this way we could be able to deliver our designs to different existing platforms out of the same design system in the future. But this is material for another possible case study in a few years.
Learnings
→ Importance of design systems
For me one of the biggest learnings of the project was: the design system is the very core and base of a digital product. It's the that combines all departments, especially the triangle of Product Management, Interface Designers and Developers. From concepting to shipping and constantly updating a digital product – the design system takes over a huge role in keeping flexibility and interchangeability for the developers and product managers as well as a consistent and well built experience for the users.
→ Good organisation is key
Designing for a scaling product requires a really well thought management and administration process for the design system, because otherwise it'll cause a lot of chaos.
→ Understand who are your users – and when do they use the application
Keeping in mind that there are always stakeholder and (different) users in a project and for every product – make sure you understand (the differences in) their goals and needs before designing solutions.
→ Remote first does work
Designing with a remote team can be fun – many thanks to Elena, Manuel and Nadir for working together with me on this project <3.
*finishing of with something funny:
At one part of the project we had so many components that Figma's memory wouldn't stop breaking no matter how hard we tried to reduce the amount of screens and components within the file. We eventually learned that we needed to structure our projects not in one Figma file with different pages but in one folder with multiple projects.
.webp)