The Globe® Pulsed Field Mapping and Ablation System is the most complete solution for atrial fibrillation, offering single-shot pulmonary vein isolation, high-definition mapping, and atrial ablation.
UX/UI design, Usability testing
Overview
Kardium Inc. is a medical solutions company that has developed an advanced system for the treatment of atrial fibrillation (AF). Their product, The Globe® Mapping and Ablation System is the most complete solution for AF, offering single-shot pulmonary vein isolation, high-definition mapping, and atrial ablation – all in a single catheter.
Timeline
May 2023 - present
My Role
UX/UI design co-op
Tools
Figma, Kanban
My Contributions
I spent 8 months at Kardium supporting the development of the The Globe software by applying lean UX design methodologies in an agile software development environment. I collaborated with the Senior UX designer, human factor engineers and UI development team on investigating, designing, testing and implementing small and large scope UX stories.
NDA protected
Please note that my work at Kardium is NDA protected. The following case study highlights the processes I undertook and an overview of the tasks I was involved in. It does not include details of the features I worked on.
how might lean UX methodologies be applied in an agile team environment to create usable, valuable and feasible design solutions?
usable
valuable
feasible
diagram from a Kardium presentation
With the development team working in 3 week increments, followed by a one on one user tests and simulated walkthroughs, we would receive large amounts of data pointing towards usability concerns. These presented themselves as UX stories which were prioritized based on the severity of the usability concern and value to the business. I approached each UX story with the double diamond model. This included investigating the story, defining the criteria for success, designing solutions and delivering the same to stakeholders.
investigation
what do users want, what are the others doing and how does it work today?
stakeholder interviews
For almost every feature request I would meet with the following three stakeholders to understand the different perspectives.
user goal : users
why is this important for you in context?
Users would be able to give me an insight into what their expectations are in context. At times I would ask them to demo the software to highlight where the pain point was being experienced. It was a rather informal show and tell/discussion than an interview.
-
What are you trying to achieve with this feature?
-
How is this goal/function being achieved today?
-
What is the workflow and where do you see this feature being integrated?
-
What are your expectations?
-
Have you already thought of an idea/solution for this?
Responses to these question would allow me to highlight the criteria for success based on the user goals, which would form the foundation of the iteration process.
value : product
how important is this on the business roadmap?
I had often heard the phrase that 'business goals are in conflict with user goals' and this was my first time experiencing it. What users prioritized was not always on the product teams business roadmap.
feasibility : development
what are we working with?
Owing to the highly customized code used for the software and regulations surrounding medical devices, I always made sure to understand the current implementation of a feature and any technical constraints we would need to work within. Further we would briefly discuss the development cost for changes to an implantation.
A quick tip I learnt from my manager was to hold these interviews separately. While it might seem more efficient to gather all stakeholders and present the UX story once, such a discussion is not very valuable. This is because each stakeholder views the topic with a certain set of goals in mind which are vastly different. Thus in a communal setting they are spending most of their time defending their viewpoint instead of elaborating on it. Further there are power dynamics in play which can add a layer of hesitation.
precedence research
Considering that the software is not a web based product and is used in a highly niche context, we had to rely on how our competitors handled certain features and their design. Since Kardium is a relatively new player in the field, it was appropriate to start off any investigation with precedence research. This allowed us to understand the expectation, which we could further iterate on.
Since we did not have access to our competitor's software and only had the public facing 'Instructions for Use' manual to refer to, I quickly grasped the technique of translating written material/data into insights that could be applied in Kardiums' context.
concept to design
balancing expectations among stakeholders
designing a today, cheap and cheerful solution and a tomorrow, target solution
In an agile software team which values incremental improvement over perfect solutions, I would always aim to provide 2 or more design solutions with varying degrees of usability, value and feasibility. While the former, a cost effective solution would satisfy the development team, the later would make users feel heard and give them something to look forward to in the future.
UX/UI design principles
It took me some time and mentorship from my manager to identify the few design principles that our design solutions would be based on. Since UX had been introduced within the company only in the past year and the software was quite mature, we had to work around the existing framework. Following are the main principles we would abide by in our designs.
usability
In a medical device company, usability is of utmost importance as it directly affects the safety of the patient. Thus, when designing the UI we would pay extra attention to factors promoting accessibility like contrast, font size and target size etc. In addition to that the goal was to produce designs that looked polished, to emphasize the value of the product without adding decorations.
consistency
Reducing procedure time is one of Kardiums' business goals which translates to increasing the efficiency with which users are operating the software. One step in that direction is to maintain consistency in the UI to make interactions more predictable over time, thus reducing memory load on users.
scalability
At a growing company like Kardium, where the product is developing at a fast pace, the UI has to be scalable. I worked on a 4 month long project of redesigning the information architecture of the software, which allowed me to emphasize this design principle. Thus, it became easier to prioritize this in our future feature designs.
discoverability
Discoverability was not a principle for this product. Users would never have to find controls or features in the software. They would always be familiar with them beforehand as they undergo extensive training. This gave us some freedom to create a layered architecture.
testing and validation
iterate, validate, defend
testing software
One of the highlights of my time at Kardium was the ability to experience different types of testings, each conducted with a different goal in mind and stakeholders involved.
UX testing - iterative
Discussing usability problems and technical restriction with mockups for qualitative data
Armed with a presentation and couple of iterations, I would recruit users with whom I would test early design solutions to receive qualitative feedback. I would conduct the moderated tests following the described framework:
-
Presentation highlighting the pain paints, the goal of the feature, supporting visuals to emphasize the same, some design documentation like information architectures (if required) etc.
-
Ask them to set up the figma file on their desktops
-
Ask them to perform the workflow within which the feature would fit in
-
Ask them to think out loud as they performed the actions
In order to be attentive while facilitating the session, I was supported by a member from the usability team who would take notes for reference.
Since these testing sessions were conducted early on in the design process validation was not the goal. Thus, in order keep the conversation generative, if a user asked me a question about an interaction, I would ask them how they expected the interaction to be, instead of defending my design.
Usability testing - validative
Testing implemented features to idenitfy bugs and minor improvements
These tests would take place towards the end of the increment when all the features worked on would be tested together. The usability team would lead these tests with UX as active observers. The goal of these tests were to identify any minor bugs that could be fixed in the same increment and usability improvements that needed more investigation in future increments.
Simulated testing - defending
Presenting implemented features to customers
These tests would take place as a way to update customers about the progress that was being made on the software. These would be in a simulated setting with a dummy patient, model of a heart, tracking system and the product. Stakeholders would assume the roles of the physician driving the catheter and clinical specialist, operating software. There was script and procedure flow to be followed with a moderator.
UX had the challenging task of both defending designs which had already undergone testing and receiving feedback for improvement, from customers.
photograph of the simulated environment
testing hardware
I had the opportunity of participating in a hardware user test session which was quite different from the software tests I was used to. We invited nurses from St.Paul's Hospital to test the new design of a hardware component. I was really intrigued by the logistics of the same:
-
It was held in a hotel room
-
We set up a simulated environment using a swimsuit stuffed with pillows for a patient, tables for the patient table and chairs and lamps as obstacles.
-
The hardware component had to be transported from the office and back, assembled and dis-assembled.
-
An honorary was given to all participants.
When they cannot come, take the prototype to them.
photograph of nurses testing out a hardware component
Following is a table which captures my learnings from the different testing scenarios I have facilitated or have been an active observer in.
UX testing
Usability testing
Simulated testing
stake
low
low
high
goal
to determine if the design thinking is meeting their expectations
to identify development bugs and respond to usability concerns
to present the features and defend design solutions
generative, iterative
tone
validative
validative, defending
1-1 with users and UX
setting
1-1 with users, usability and UX
room with users, customers, usability and UX
who facilitates it
UX
Usability
Usability and UX
stakeholder endoresement
Following are a few comments made by stakeholders within the company about a complete overhaul of the UI done by me in collaboration with the senior UX designer.
" It reminds me of a Tesla's interface now - the nested architecture and modern look ."
key stakeholder
" The menus are much more usable and contemporary. The toolbar is more intuitive and accessible. Makes a lot more sense, fewer clicks and invisible which is great."
key stakeholder
continuing at Kardium
involving myself in processes before the ux story lands on my desk and after it has been handed off to dev
contextual inquiry
Watching a live case at a clinic with physicians and software operators using the Globe software to perform a procedure might be in the horizon for me soon 🎉. Since we do not get an opportunity to interact with the context on a regular basis, I would like to take this opportunity to conduct a contextual inquiry in collaboration with my manager to follow physicians, nurses and fellows as they use the product (both hardware and software) in context. I have been reading the book 'Rapid Contextual Inquiry' and owing to the leaps and bounds with which the product is growing, these sessions would be very useful.
an insight to a UX story
Up till now, I have been made aware of a feature request/improvement from my manager. As a result of which the problem statement or area of investigation is quite well defined which allows me to jump straight into the design at times. I am however interested in learning how a statement from the product teams roadmap is translated into a UX story. To further this goal of mine, I am currently working on a project that allows me to start from the very beginning (i.e. an idea in an excel sheet), to identify how UX might intervene and interpret it as UX case.
edge case discussions
"What would happen if...?" is a statement I often heard from developers when we presented them with our design solutions. During the development cycle, my manager would constantly be communicating with developers, answering their questions about certain edge cases. These would sometimes lead to more improvements to be made. Now that I solely have worked on some features, my manager is mentoring me through the post handoff discussions.
reporting bugs
During software walkthroughs, we would identify some bugs in the implementation which needed to be fixed considering that in a medical device software, the bugs had to be in single digits. While I had identified some bugs, I always reported them to usability who would communicate the same to development. I am however intrigued to learn how it was described to them and am thus being mentored through that process by a colleague on the usability team.
see more
