Thought about the biggest frustrations of many iOS users when receiving a second call. Based on Apple's HIG ↗
After being approached by the support specialist, we wanted to understand wether this issue was a recurring pain-point amongst users, and to ensure we weren’t designing in vacuum, we wanted to see real world comments regarding the issue.
By starting our research process with direct user sentiment, we ensured that the redesign had its base in clearly acknowledging the real-world issue causing degraded usability in high-pressure, time-sensitive settings.
The product manager was responsible to quickly draft business goals that need to be addressed with the design process. During this, I collaborated with the PM on different stages.
With the problem validated we felt comfortable enough to move to the deeper research to examine how competitor handle second call scenarios. Our goal here was not only to map out the different features that others offered, but to extract design principles that would aid in the future solution for the iOS second call screen in the ideation phase.
Although the data shows that iOS is the mostly used OS in the USA, Android is not that far behind, moreover, globally, Android users exceed iOS users substantially. This doesn’t necessarily mean that the solution to this issue is addressed better within the Android OS, but we should definitely have a look and investigate their flow for a better understanding overall.
After investigating what each competitor offers in times of receiving the second call, it was evident that we had to measure their performance on some key aspects to clearly see the things that are handled effectively and the aspects that still can be improved. These insights will weigh in later, when we start thinking of solutions to improve our current iOS screen
Getting a visual representation of the competitor analysis that sums up the overall state of the iOS solution when compared to other Android solutions in the market used daily
With this spider chart, we were able to communicate the results of our competitor analysis more visually which helps us communicate our findings to other stakeholders and product people.
All this competitor analysis comes to an end we had a few global heuristics that were clearly evident, and in terms of involving other teams when presenting how we got to the solution, these heuristics are the main points to articulate
In the second stage, we conducted a real world, qualitative user research with two participants (Mom, and Wife) to better understand their behaviors, pain points, and expectations when receiving their second call. We decided not to do an empathy map since it’s value emerges with larger data sets, and instead have grouped their answers into an affinity diagram with their respective themes.
With all the real world insights from the two user interviews we did, and with this affinity diagram, we felt confident to move to the last stage of the research plan, which was to create a persona that depicts the users we have been working with, and to formulate a problem statement that will be our main focus in the coming stages.
With all the real world insights from the two user interviews we did, and with this affinity diagram, we felt confident to move to the last stage of the research plan, which was to create a persona that depicts the users we have been working with, and to formulate a problem statement that will be our main focus in the coming stages.
We didn’t do any of the fake additions in the time that we had. Keeping in mind that we needed a solution that was an MVP and could be delivered quickly, we created a lean persona that summed up our research and helped us frame the problems we were facing.
iPhone users who receive multiple calls at the same time often feel panic and frustration, because the second call screen is structured in a way that leads to mistakes and unintended actions.
With solid research complete and alignment of all findings with the product, it was time to take into consideration that work, and start the ideation process.
To remind us of what are the things to focus on, we put at the top of our drawing boards the design heuristics form the competitor analysis, the design success goals, and the problem statement. By doing this, we always had in front of us, in plain sight, the key guiding points of the research process.
With all the real world insights from the two user interviews we did, and with this affinity diagram, we felt confident to move to the last stage of the research plan, which was to create a persona that depicts the users we have been working with, and to formulate a problem statement that will be our main focus in the coming stages.
We didn’t do any of the fake additions in the time that we had. Keeping in mind that we needed a solution that was an MVP and could be delivered quickly, we created a lean persona that summed up our research and helped us frame the problems we were facing.
Two solutions were chosen as the contenders that would move forward to the LoFi wireframe stage. In this stage we would created those ideas in a bit more details, understanding the user’s flow in a few screens. Ideally one of the contenders would move to the UI stage to be finalized and handed off to development.
Here’s the standard iOS screen when a user is on a standard call. They have their main action button to End the call, and other secondary buttons that are not relevant in this study.
When they receive a second call, a sheet slides up from the button highlighting the second caller by casting an overlay on the main screen under it. The sheet covers up all actions related to the current caller hence concentrating the user on the task at hand: answer or decline the upcoming call.
If the user answers the call, the first caller is put on hold and the call is minimized at the top. The card hints the user that the first call is on hold and has a chip for the user to end it at any time. The second call now takes the entirety of the screen and becomes the new focus of the user.
If the second call is declined, the user goes back to the first screen.
This option clearly articulates the first and the second caller at the appropriate time, always articulating to the user with which caller they are interacting with.
The actions in this flow remain simple and do not cause any cognitive load to the user. Although the first caller has 6 action buttons, the sheet that comes up with the second caller, hides all of that and proposes 2 simple actions.
In this case we use iOS’s native “Accept” and “Decline” buttons, as creating a new unified component at this stage is not appropriate to do, since we have a strict deadline and an MVP is expected.
The use of the sheet that slides up, has a layout that is almost identical to the incoming call when a phone is unlocked, meaning that the familiar elements in their usual places ensures a quick response
This flow behaves as user expect it in terms of putting on hold the current call to answer the second one, which is the primary flow of Android, as well as Landline. However users also expect an option to end the current and answer the new call, which is missing in this solution
This solution leverages sheets that slide over the existing UI to focus the user’s attention on the second caller. It simplifies the decision to a clear binary choice, which supports speed and clarity. However, by using the entire screen more effectively, we could also support the “End & Accept” option — a secondary but important action for many users. Addressing this need in the next iteration will help us balance simplicity with flexibility, and strengthen the overall solution.
Two solutions were chosen as the contenders that would move forward to the LoFi wireframe stage. In this stage we would created those ideas in a bit more details, understanding the user’s flow in a few screens. Ideally one of the contenders would move to the UI stage to be finalized and handed off to development.
Although two callers may exist, only one is always the primary focus. The other is minimized into the Dynamic Island, reducing confusion and preventing split attention.
The solution reuses the same UI patterns users already know from single-call and incoming-call screens. This ensures smooth transitions and builds on muscle memory.
Incoming second calls present three clear options, structured into primary (“Hold & Accept,” “Decline”) and secondary (“End & Accept”). The hierarchy keeps actions predictable and reduces cognitive load.
The design leverages iOS’s native buttons for “Accept” and “Decline” to meet MVP constraints and ensure speed of delivery. A new unified control could be explored in a future iteration.
The flow mirrors real-world calling behavior and platform conventions: answering one call puts the other on hold, while secondary controls remain accessible in the Dynamic Island. This aligns with user mental models
This solution prioritizes clarity by always keeping one caller as the user’s primary focus at all times, and minimizes the other into the Dynamic Island to reduce confusion. Using familiar iOS call screens and patterns ensure consistency and quick action. The actions are split into primary – “Hold & Accept” and “Decline” and a secondary – “End & Accept” which covers user’s needs. The flow supports user expectations by mirroring real-world calling behavior and platform conventions: answering one call automatically places the other on hold, with secondary actions still accessible. Finally, by leveraging native iOS components, the design delivers an MVP-ready solution quickly, while leaving space to refine unified controls in future iterations.
After careful consideration and revision of the lofi wireframes, we came to the conclusion that the second option provided more value to our users, and targeted each and every one of the design heuristics, and took into consideration the problem statement
To kick off the UI, we used our own Figma UI Kit, to keep everything consistent with the Apple language, and to have a swift transition into development. Although our UI Kit provides the guidelines and the atomic components, we had to create case-specific components to show visually what the solution components are, and to prototype to as real-life as possible with Figma.
This concludes this case study that was meant to provide a quick solution for the second caller screen, of course when implementing solutions like this, all other products of the ecosystem at Apple should be taken into consideration, however for this case study, our main focus was the iPhone.
Hope you liked this case study and if there are any questions feel free to contact me!