ICEBERG: An experiment in human connection.
Role: UX Designer, UX Researcher
Client: Ikram Hoque, founder of ICEBERG
Key Performance Indicator: A goal of 80% task completion and positive feedback from usability testers.
In the words of Ikram Hoque, founder of the ICEBERG application, “Our networks are like an iceberg, with 90% floating below the surface despite being able to add tremendous joy to our lives.” If that’s the case, how might we leverage the joy of human connection to bring more of one’s network to the surface in a meaningful way?
Executing an end-to-end UX design process for our client, my team and I, a team of three, designed the mockups for the core functionality of this new remote communication app, conducted important user research, and, based on our synthesis, added several new features that we validated through usability testing.
Setting the Stage
Before our first stakeholder meeting with Ikram Hoque, the founder of ICEBERG, we knew very little about the product idea besides a simple website landing page that he had created. So we were eager to meet with Ikram and dive in. When we finally had our first stakeholder meeting with Ikram, with learned a great deal about his vision and what he had done on the project so far. Some of the main takeaways from this first meeting included Ikram’s high level objectives for his app’s mission:
Create a go-to space for nostalgia, elation, and excitement, without social media overwhelm (ads, newsfeed, etc.).
Capture the simple joy of serendipitous human connections when users want to engage with each other.
Leverage a “double opt-in system” to minimize “time to joy.”
The double opt-in system refers to the idea that if two users opt in to a product whose core objective is to establish meaningful 1:1 human connection through intentionality, people would feel less awkward about reaching out and talking to people deep in their network, ultimately minimizing the time it takes to experience the joy of human connection.
Ikram asked us to design the core User Interface for the app’s main features and create an effective onboarding experience.
Initial Thoughts
My initial thoughts about Ikram’s high level objectives for ICEBERG leaned toward skeptical. His product idea seemed useful perhaps, but he hadn’t necessarily pinpointed a significant user problem in the world of remote connection apps. Haven’t all the user problems related to remote connection already been solved by myriad social apps? Is the founder overestimating how much people actually want to reconnect with old friends?
Despite these concerns, I knew that I needed to set aside my own assumptions and remain open. Ikram had done a fair amount of user research on his own, but he admitted that much of his research may have contained bias. “I don’t know what I don’t know,” Ikram told us. So we knew that additional UX research would be crucial to the product’s design.
Empathy and Human Connection
We conducted eight user interviews asking each user a range of questions to dig deep into their use of social and communication apps as well as the way they value human connection. We wanted to find out what pain points exist, if any, in a market saturated with ways to connect with other humans.
Some of the most important trends from our user interviews included:
Human connection is critical to individual and societal well-being, but most users feel some form of anxiety about reaching out to people who are not in their immediate circles.
Many users felt that it is very difficult to achieve meaningful human connection through existing social apps.
These were some of the significant pain points that emerged as trends in the interviews, but it could still be the case that these problems were already solved by existing platforms if our interviewees weren’t aware or interested in those options.
We realized that we needed to conduct a competitive and comparative analysis to take a deeper look into what problems contemporary communication apps do and do not solve. What would set ICEBERG apart from what’s already out there?
Through examining the features of a range of popular social/communication apps including Discord, Houseparty, Clubhouse, Signal, and others, we found that few apps offer ways to achieve the joy of one on one human connection while eliminating that anxiety of reaching out to someone. Many apps offer “user joy” by facilitating human interaction, but fall short of providing a means for users to dig deeper into their networks in an efficient and meaningful way.
What’s the problem?
Users need a way to spark and maintain conversations with those who matter most, past and present, so they can experience the joy of human connection deep within their networks, on their time, and without hesitation.
In order to exercise empathy and create effective solutions, we created several personas based on our target users to bring the user experience to life:
Creating user personas in the UX process is very helpful in terms of maintaining empathy, but in order to further elucidate our users’ scenarios with regard to the ICEBERG app, we created a user journey based on a “current state” and “future state” if they were to use the product to solve their pain points:
The Solution:
Our research validated the need for the core features requested by Ikram. However, our team included several additional features, such as the weekly question, to solve particular pain points highlighted in our user interviews. Our mockup/prototype included the following features:
Onboarding experience to familiarize the user with the product so that they have a sense of opting in to app’s experience and shared mission.
1:1 communication functionality, including a call queue geared toward for serendipitous connections.
Call feedback feature so that users can write notes after calls.
Contact organization and scheduling feature for efficient more contact planning.
Weekly question feature to serve as conversation starters and reduce the anxiety of reaching out.
How did we get there?
After conducting and synthesizing some rewarding research, my team and I were eager to jump into the ideation and sketching phase.
As we launched into sketching, we couldn’t help but think about all the possible ways to solve our users’ problem. This became one of our challenges as a team in the post-research phase: we spent a great deal of time and energy brainstorming and ideating on possible solutions. These ideation sessions ultimately worked to our benefit, but we should have timeboxed more. Our client had asked us to focus on the onboarding experience and core UI for the one-on-one communication functionality. So we conducted several design studios to rapidly generate visual design ideas.
Once we were satisfied with the design ideas that we wanted to move forward with into digital wireframes, we began by creating a mid-fidelity prototype:
As we sketched and wireframed, ideas of additional features kept percolating to the surface. We realized that there was a good reason for this. Our interview data suggested that the “double opt-in system” was not going to be enough to entice users to download the app, nor would it be enough to maintain longer term usage. There needed to be some additional magic to help ICEBERG solve its user problem and stand out from the competition.
One of the main communication barriers that multiple interviewees expressed included not knowing what to say when they reach out to someone. So to address this issue, we came up with a “weekly question” feature where users can answer a randomly generated fun question on a weekly basis and see other users’ responses. These questions/answers could act as conversation starters if needed for users to connect. Additionally this feature could be a reason for users to return to the app on a regular basis.
Sample screen showing the “weekly question” feature.
We briefly struggled with whether or not to include the weekly question feature because it was not something that the founder had asked for, and Ikram, ICEBERG founder, had expressed indifference about the idea of conversation starters. Were we wasting our time with a feature that our client may just get rid of? We pitched the idea to Ikram and he really liked it, so we moved forward. We also knew we could test the feature.
Usability Testing: Round 1
We really needed to run usability tests for all of our features/flows, so we recruited four users for our first round of testing using our mid-fidelity prototype. This first round of testing yielded some important trends:
Given the difficulties our testers had with various aspects of the prototype, we were far from meeting our KPI goals, despite the encouraging feedback we got regarding the weekly question feature that we added. We knew we had iterating to do. We needed to:
Make the functionality and purpose of the call queue much more clear.
Make the onboarding screens easier to navigate and understand so that they are not just passively swiped through.
Rework the weekly question feature to increase ease of use. However, the positive feedback that we received in general regarding the weekly question feature was very encouraging and was an important validation of our decision to include it.
Below are some of the important iterations we made based on the first round of user testing and meetings with Ikram, ICEBERG founder:
In order to assist with users’ understanding of the call queue functionality, we added a tool tip screen provide some context when the user first interacts with the feature. In addition, we added the “Tip of the Iceberg” section so that the user can scroll through and select frequent contacts.
Originally the users’ entry of their response to the weekly question appeared as an overlay interaction, but our testers found this confusing. So we changed the interaction to an inline form field. We also added the penguin mascot to be more inviting than a plain quesiton mark with a dark background.
We decided to include the penguin mascot in more places throughout the app given positive feedback regarding it from our testers. In addition, for the mockup we decided to include the ICEBERG icon as the image for the call queue to draw more attention to the button on the bottom navigation bar.
The above shows the transition form the mid-fidelity wireframes to the color mockup of the onboarding screens. We considered that one of the reasons our initial testers might have had trouble with the onboarding experience is because it was a grayscale wireframe, providing little surprise and delight. So we kept the onboarding screens more or less the same for the mockup, but added colors, light gradients, and the penguin mascot. We decided to see how things went with the color mockups in a second round of testing.
Usability Testing: Round 2
Our second round of testing, in which we had users perform tasks within the mockup prototype, validated some of the changes we had made and highlighted major iterations that still needed to take place. All in all, the results were similar to round 1:
The majority of users still had some difficulty with the onboarding section, whether that was with navigation or understanding the concept of the app. So the color mockup with imagery etc. did not improve the efficacy of the onboarding experience. With more time, the onboarding screens would need to be reworked.
The majority of users still did not understand the purpose of the call queue despite the iterations we made, since one can also go directly to a contact and call them within the app.
The feedback that we received regarding the weekly question feature was even more positive after adding the color and imagery. Some of the users were critical of the entire concept of the app except for the weekly question feature.
Next Steps
With more time, we would:
Add “tagging” features for organizing contacts into customizable groups such as family, college alumni, close friends, etc..
Continue to iterate on the onboarding experience and call queue feature since our testers experienced pain points with these after our second round of testing.
Add a weekly question history to see previous questions/responses.
Explore gamificaiton possibilities.
Research and ideate on user experiences conducive to monetization.