Edison by T-Mobile
Edison by T-Mobile is an enterprise application for businesses to be able to communicate internally both in the field and in the office. For T-Mobile business customers, this application will be the replacement for the desk phone and will consist of communication features such as calling, messaging, leaving voicemails, and creating contact groups for quickly reaching distribution lists.
The challenge
My main role on this project was to design the calling features at first. However, as the project continued, my role evolved to include a more holistic approach and I also had a hand in designing messaging, details, contacts, and settings alongside my teammates. One thing we were really focused on when designing the desktop leg of this application was the framework being easily accessible for multitasking. We wanted to create a system that could be broken down in several ways to account for people who would be involved in phone calls related to work but also might want to work within other windows and different apps or with different portions inside Edison itself. We knew we had more space to work with so we wanted to maximize this space while still allowing for a focused and non threatening experience. In addition to the challenges of multi tasking, we were designing based on systems already in place from the mobile experience so we had to keep it consistent while also making it a unique experience. We also had to worry about time constraints for shipping and versus all the things we had in mind conceptually.
Ideation
We spent the first few weeks doing a lot of conceptual work. This conceptual work included figuring out what the header navigation would include - or if we’d use a sidebar for organization purposes instead, how the “blades” would appear, where the settings would live, where the search bar would sit and other framework related challenges. During the whiteboard stage, we used market research, looking at apps like Slack, Microsoft Teams, Google Hangouts, WhatsApp, Skype for Business, and Facebook Messenger.
We took the idea of a card and flattened it so that instead of including a Z-axis design, different forms of the app would include pieces that slid in and out fluidly upon command. Using this inspiration and the multi-tasking ask, we came up with a system that would allow users to “pop” windows off the original window so that they could multitask in those smaller windows while still focusing on whatever main task they had at the time. This was the main conceptual direction we wanted to go when considering the various systems in the desktop application. Once we had this main POV down we could start filling out the other areas and the details.
Design iteration
Once we had the framework ready to go I started designing calling. I took the general flows from the mobile experience and tweaked them for the desktop. There were many small differences that had to be taken into account. In order to make a multi-tasking friendly calling experience, every time a call was placed or received a new window was spawned for that call. From this separate window, all the calling actions would be made. When someone needed to view more details in this window, it would grow to accommodate an action that needed more focus, such as when a user wanted to view the contact details for the user they were on the phone call with. This went through many iterations until we whittled it down to an experience where the window expanded less and communicated with the main window more, allowing the user to use the calling window as a focus state and the main window as the area that most of the work actually happened.
The key here was that the popped out calling window communicated seamlessly with the main window and they worked together to create a tandem experience, only pulling in the other when needed. After finishing the calling experience here, I started lending more of a hand to the other sections of the application, such as the messaging and contacts. Because I had my hand in many of the places that the app worked on a high level, and I had worked on the framework, I was able to make pattern decisions that could interact with the different areas smoothly.
During this same version of the framework, I played with many different iterations of the how the buttons would be presented internally. I wanted to make sure that, like the rest of the desktop experience, they aligned with the mobile application so you can see cues taken from the mobile experience while also seeing small improvements based on how the web application was set up. These details also changed over time based on internal critiques, overall framework tweaks, and shifting acceptance criteria. Above you can see the different ways to start a message with the ongoing caller from the call.