Added a feature for uploading large files to cloud storage

My role: Senior Product Designer.

Team: Product Owner (2), UX Architector (2), UX-Writer (2), Product Designer (2), Backend and Frontend developers.

Tools: Figma, FigmaJam, Confluence, Jira.

Products: Mailion (corporate email), FM (file manager).

Year: 2022.

1. Summary

We implemented the functionality for uploading files to the cloud for email clients and completed one of the important stages of the grant for product development.

2. About the task

At «MyOffice,» we were developing an ecosystem that unites all the company’s products: document editors, spreadsheets, presentations, messenger, email clients, calendars, and file manager. We aimed to integrate different parts of the product as much as possible to provide our users with a universal experience when using our products.

In this case, we will consider the following products of «MyOffice»: "Mailion"—a corporate email based on the Cloud Native platform, and "Private Cloud«—a secure solution for storing and managing files in your cloud with built-in document editors.

2.1. The Problem

Mailion has restrictions on sending files that exceed the set quota. This limitation is controlled through the admin panel and applies to both individual files and the total volume of all attachments, as well as the overall email quota for each user. The maximum quota size is 50 MB. These restrictions can make it difficult to send large files, even though such transfers are sometimes necessary. For example, when you need to send installation files to colleagues. Unfortunately, the use of public cloud storage in the company is not allowed, and there is no way to use our own.

It was decided to implement a widget in the form of an iframe on the «Private Cloud» domain. This solution greatly simplifies internal integration between MyOffice products. Additionally, thanks to the API on our side, external integration with various software used by our business clients also becomes easier.

2.2. Process Organization and My Role

This task required parallel work from several product teams, so cross-team interaction became an integral part of the process. I worked in two teams simultaneously: «WFM (product ’Private Cloud’),» where I participated in the development of the UX for the MVP widget, and in my main team «Mailion,» where I designed the interface for cloud file uploading to corporate email using the new widget.

2.3. Research in the WFM Team

At the initial stage of familiarization with the task, we studied all available documentation, requirements from the Product Owner, and grant conditions (this functionality was an obligatory part of its completion).

2.3.1. User Story Map

We conducted interviews with the target audience, the results of which we formatted into a «User Story Map» framework. In it, we prioritized the solutions to the most important tasks for the first release:

  1. Transferring data from the cloud to another user via a link.
  2. Transferring data from the cloud to another user as attachments.
  3. Uploading data from a local device to the cloud with subsequent sending via a link.
  4. Uploading attachments to the cloud that exceed the available quota when added to an email, with subsequent sending as links.

2.3.2. Jobs To Be Done

Also based on the interviews, we compiled the main jobs:

  1. When I need to place a file or folder in the cloud, I want to upload it so that further operations with it can be performed in the cloud.
  2. When I upload a file or folder to the cloud, I want to know the upload status to be sure the upload is in progress.
  3. When I upload a file or folder to the cloud, I want to know the upload status to understand how much time is left.
  4. When I upload a file and a conflict arises that requires my participation, I want to receive a notification about it so that the upload is not delayed.
  5. When I upload a file or folder and go offline, I want the upload progress not to be lost and to continue after going back online to save time and traffic.

2.4. Designing the UX Widget

For the convenience of communication with the development team, we created a short glossary of terms:

  1. Objects—files and folders that users work with.
  2. Host Application—an application that calls another application and receives data from it. In our case, the Mailion email client acts as the host application.
  3. Widget—an application launched in an iframe by the host application to select data for the email and send it to the host application. In this context, «Private Cloud» is the widget.

Also, together with the WFM team and the development team, we designed the widget architecture, which allows the user to work with two connected systems—"Private Cloud" and email clients, which interact with each other through built-in interfaces and API requests. The «Private Cloud» frontend performs its tasks, while the email frontend manages operations related to email through the Mail Backend.

2.4.1. Widget Usage Scenarios

At this stage, we worked with low-fidelity prototypes. This allowed us to focus on structure and functionality without being distracted by final visual design and to spend more time designing the feature itself.

In joint meetings with the «Private Cloud» and «Mailion» teams, we discussed integration limitations from the products and technical capabilities. We also defined the areas of responsibility for the teams, considering that part of the feature would be cross-functional for the widget, and the host applications would need to take into account the specific design features of the product.

2.4.2. File Upload Scenario to the Cloud

When uploading files to the cloud, the user interacts with the attachment entry point in the host applications. Clicking on it initiates the widget opening. Then, the user follows the familiar file selection flow from the file manager.

During the discussion of this scenario, we found that implementing the functionality was impossible without separating it into individual system dialogs for selecting files and folders.

2.4.3. File Upload Scenario from a Local Device

When uploading files from a local device, users will also face quota restrictions, but now they will be able to use the file upload feature to the cloud, which exceeds the limits.

All cloud files in the first phase are saved in the root of the «Private Cloud» disk in the «Mail Attachments» folder; in future iterations, it will be possible to select another folder.

We also found that in installations without «Private Cloud,» all public links would be prohibited, or public links could have a password. In this case, we will have to block this feature.

2.4.4. File Upload Scenario from the Cloud

The user can attach already uploaded files to the cloud as attachments and links using the «Private Cloud» widget.

In this scenario, we paid special attention to working with «Private Cloud» public links. A file can have from 0 to 2 public links (automatically created when the file is first sent and by the user). To avoid situations where access to an already sent file is lost, we decided not to take user links into account. If the file does not have a public link, it should be created when attached. If a public link exists, we use the existing one.

For the method of adding files from the cloud «As attachments,» quota limits will again apply, and in this case, a notification should be shown in the interface that all or part of the files exceed the limits. We also cannot add folders as attachments because we do not know the archive size in advance and cannot assess compliance with the quotas. In this case, there should also be a warning for users.

2.4.5. Email Viewing Scenario with Attachments

Users, viewing an incoming email with attachments, can:

  1. Visually examine the files using preview or full-screen viewing.
  2. Download files to a local device.
  3. Upload files to the cloud. In this case, the files in the cloud and the correspondence will be independent of each other—changes in the cloud will not affect the files in the email. This behavior is due to the lack of connection with the original files on the user’s local computer, as all interaction takes place through the corporate email backend.

2.4.6. Results of Work in the WFM Team

Together with various teams, we developed the logic of the new functionality. We carefully analyzed the constraints and determined which elements would be part of the widget and which would be part of the host application. This work was carried out iteratively: after each meeting, we recorded the results to avoid misunderstandings and maintain clarity in the agreements reached.

As a result, we designed the widget’s UX, and then each designer continued integration into their team’s product.

3. Widget in Mailion

3.1. Sketches

In the WFM team, we agreed on the concept in the form of a modal window, but when starting work in Mailion, our development team opposed this solution and insisted on using the «Media Panel» component: this is an interface element that opens over the main interface or as a separate column, depending on the breakpoints.

The reasons for this contradiction are related to the fact that we tried to avoid using modal windows whenever possible, as their use caused performance issues for the client.

But this solution was inappropriate and destroyed the entire integration concept. To reject such a solution and find a compromise, I held a meeting with the developers and the product owner, where I presented several arguments why the «media panel» was a bad solution:

  1. Inconsistent behavior: if we limit the use of the media panel only in Mailion, we will break the unified user experience compared to other products where the modal window is used.
  2. Limited interaction area: a block 320 pixels wide is insufficient for comfortable work with a file manager that has a tree structure.
  3. Duplication of work: although the widget has an API that can be connected to an iframe, we will need to create many new unique components for its implementation in the media panel. This is inefficient and will lead to unnecessary complexity.
  4. Mixing scenarios: using the media panel adds another context to the email composer. Users face information from different interface zones, which should be avoided. User behavior research in Mailion confirmed this problem.

The team agreed with the arguments presented, and we decided to abandon the use of the media panel. As a result, I returned to the initial idea of implementing it as a modal window.

3.2. Final Design

My layouts will be used by various specialists: developers, designers, product owners, testers, and UX writers. Therefore, I aimed to make the work in Figma as detailed as possible, with descriptions of all scenarios and explanations. This approach will allow employees in different roles to work more efficiently with the layouts and improve communication during product development.

In Mailion, a deployment was added for different file upload scenarios by tapping on the attachment icon; previously, only the system file manager would open. After selecting the «Upload to cloud and send» or «From cloud» options, the user will encounter the iframe widget.

3.3. Additional Improvements

We also managed to improve the drag & drop functionality, making it more convenient for users. Previously, the interface did not display visual changes when dragging a file into the email client’s area. In the new version, we significantly improved this scenario. Now, when dragging files, the user will see a division into drop zones: into the email body or attachments.

When dragging large files or folders, the interface adapts and clearly informs the user about the further fate of the added files.

4. Conclusion

Working on this project, I gained valuable experience and learned important lessons. First, integrating multiple products into a single ecosystem showed how critical careful planning and effective cross-team interaction are. I realized that early identification of constraints and potential conflicts between teams and products is crucial for successful implementation. Second, I understood that successful implementation of complex projects requires flexibility in process management and adaptation to changes. We had to repeatedly revise our approaches and find compromises to balance the different priorities of the teams and ensure the timely completion of tasks.

If I could change something, I would propose developing an approach that would allow the teams to work in parallel, avoiding unnecessary delays. The project dragged on due to the different speeds of task execution and discrepancies in priorities: some teams progressed faster, while others postponed work due to other urgent tasks.

Moreover, this functionality had a high priority within the grant for development, which allowed the design team to earn a significant bonus for their work.

Thank you for watching.
You can rate the case if you liked it.