iOS SDK Attachment Cell Enhancement

My aim for this project was to design an enhancement for an existing component in SAP’s Fiori for iOS SDK.

MY ROLE: UI/UX designer

BACKGROUND:

A stakeholder (SAP SuccessFactors) requested an enhancement to the existing Attachment Cell component in our Fiori iOS SDK based on their customer needs. The same request was made for the counterpart in the Fiori Android SDK.

The request was to add file size information to the component, which initially only displayed the file name and a placeholder or image thumbnail.

END USERS:

SAP SuccessFactors’ customers. Given time constraints and a lack of access to real end users, I relied on SuccessFactors to act as a proxy for their customers. They provided their customers’ needs (kicking off this project) as well as feedback on my designs.

PROBLEM STATEMENT:

Users need to see their attachments’ file sizes in order to determine how many attachments they can add and whether they can add additional ones without deleting an existing attachments.

How might we include file size information in our existing attachment cell component in a way that is easily consumable for our users?

HIGH-LEVEL OBJECTIVES:

• Design an iOS attachment cell component enhancement to accommodate file size information

• Align enhanced component with Android’s enhancement to ensure enhancements reflected the Fiori design system

To start, I took a look at other grid styles in various apps to see how more information could be displayed.

There were two common approaches:

1. File information displayed in a cell overlay

2. File information displayed below the cell

I also compared the existing iOS component to Android’s counterpart.

Compared to the current iOS component, the Android counterpart had a different UI (a gray overlay at the bottom of each cell) that could potentially stretch to fit file size information.

Based on my quick research, I came up with various explorations leveraging the current iOS design as well as the Android design.

A couple of the explorations simply played with the size and placement of image thumbnails to add file size, while other explorations played with file information in an overlay similar to Android’s existing design.

After showing my explorations to other iOS designers on my team, I found that there were concerns over accessibility with text over the placeholder icon as well as with the overlay.

In my following reiterations, I eliminated explorations where text is displayed over the placeholder icon and increased the contrast between bottom overlay and the text to address accessibility concerns.

I reviewed the reiterated explorations with SAP SuccessFactors and clarified a couple questions that came up as I was designing.

STAKEHOLDER REVIEW — KEY TAKEAWAYS:

• Overall, stakeholders liked option 3A but felt that it looked cramped.

• In the initial iOS design, no file information is shown when there is an image thumbnail. However, customers need to see file size information because it’s important when they’re trying to determine whether they can upload additional attachments. That information should always be shown whether there’s an image thumbnail or a placeholder.

• In SAP SuccessFactors’ web version for attachment grids, there is a lot of file information besides file name and size. A sustainable and long-term design solution might be worth exploring in case there needs to be additional information displayed in the future.

Based on their feedback and reviewing the Android designer’s explorations, I reiterated my overlay designs, added a text chunk for optional information, and designed additional explorations where file information is moved beneath attachment cells. I also tried playing with the attachment cell sizes to accommodate more information.

I found that overlay designs did not translate well to dark mode — the overlay blended into the cell.

I reviewed the explorations again with the larger iOS design team and shared my concerns about the overlay in dark mode. Overall, most preferred the option with file information underneath an enlarged attachment cell.

STAKEHOLDER REVIEW — KEY TAKEAWAYS:

I shared again with the stakeholders and found that they strongly preferred option 1A:

• It’s the clearest and cleanest design.

• It avoids accessibility issues.

• It’s the most forward-thinking design: there’s an option to add more information in the future.

Given the limited timeframe and resources, I relied on the stakeholders, SAP SuccessFactors, to provide user-centered feedback on behalf of their customers. I validated the design during design reviews with them as well as with the broader iOS design team.

As the design is implemented in the future, I expect to receive additional feedback from end users.

CONCLUSION:

Overall, this was a relatively minor enhancement to an existing iOS component that resulted in a significantly different design than the original.

I found that the stakeholders had more future-reaching concerns about the component than I initially expected, and that shaped the direction of the enhancement as we continued to review explorations.

It was also extremely important to communicate with the Android designer who was designing the Android counterpart to ensure that the enhancements were aligned and reflected the Fiori design system. Android designers on the team actually preferred the overlay style rather than file information underneath the cell, but the stakeholders firmly preferred the latter.

NEXT STEPS:

I’ve created Figma design specs and handed them over to iOS developers. Once development starts, I expect to clarify any questions and see implementation in the next SDK release.