Brief Description

sBox is a mobile and desktop solution targeted at corporations to privately store their files in the cloud while allowing their users to manage their own files and share them within the corporation. Basically, you can think of sBox to be a privately-owned Google Drive or iCloud.

Since I was a Singapore Management University student, startups from my school started approaching me after seeing my SMUMods project. One of the startups, RushOwl, agreed to work with me for 2 projects — this project sBox as well as their upcoming mobile application. sBox is UI design-focused while Rush Connect is more UX-focused.

The sBox project is not owned by RushOwl. Instead, one of the SMU professors approached them to ask for their help in UI design. Since I was already helping them with their UX, I was looped into this as well. I was in-charge of the entire UI design for this project.

Updated design

• For every flow, you will find 2 sets of screens, with the second set from the 2nd iteration.

Expertise UX Research, Design

Platforms Mobile, Desktop, Web

Deliverables UI Design, UI Design System

Prototyping Tool Sketch

Design Process

Since this project was UI-focused, I simply have to know what the users can do, how many types of users there are and whether they can provide any wireframes they have already done.

My first meeting with sBox was mostly a stakeholder meeting, mainly to understand what the app was about and what the app could do.

Some requirements

• sBox has 2 types of users — the end-user and the admin.
• The end-users will use both mobile and desktop versions while the admin will primarily use a desktop management UI.

User Flows for End-Users

The best way for me to ensure that I have enough information to work on is to visualise everything in flows. As long as the flow is complete, there shouldn’t be any missing screens. Also, by visualising during the meeting itself, I could ask them questions on how certain flows are done and get clarifications immediately.

In the following paragraphs, I will explain the user flow, their current wireframe for that flow and my finalised UI design.

1. User Authentication Flow

Every end-user will be given a username and password to login to the sBox app. This meant that there will be no registration page. I believe this kind of login would require a first-login-password-change page for users to protect their account which sBox confirmed during the meeting when I voiced it out to them.

2. Filesystem Flows

A) Home & File Actions

Once the user logs in, they will go straight into their root folder. For simplicity sake, I've went ahead to populate the view to show all the different file format icons. This design is heavily inspired by Google Drive, which I think is one of the better cloud storage solutions.

Since this application will be used by corporations and education institutions, I imagine that the most frequently used icons would be the following:

1. Media (Audio, image, video)
2. Microsoft suite (Excel, Word, Powerpoint)
3. PDF
4. Code

Courtesy of Font Awesome 5 fonts, these icons were also reflected in their list of icons.

The modal pop-up is a non-intrusive, providing a usable way to tap on the most important buttons such as copy, cut, rename and share while the top is filled with details instead of actions.

When I was still using Android, I was very picky about file manager applications. I would pick an app based on the efficiency/productivity it provides. Thus, I picked and designed the best way I know to copy/paste files. My main point here is to ensure that users know whether the app has registered user actions (copy/cut) and show the paste button clearly. As such, when a user copies or cut files, there would be a persistent bottom-custom-snacker to indicate their action and their call-to-action (paste).

B) File Sharing Flow

This is the hardest flow of the entire application. When I heard about the constraints and requirements for sharing a file, I knew immediately that more work has to be done here. Below are some of the requirements/constraints given by my client:

1. Files can only be shared to groups of users that belong to 'attributes'. There is no link to share and no way to specify emails addresses.
2. Each user belongs to one or many 'attributes'
3. Attributes can be stacked -- for example, choosing 'School of Business' and 'Students' will choose only users that satisfy BOTH the criteria. Thus, the users chosen will be Students that come from the School of Business.
4. Attributes can also not be stacked -- in the same example as above, you can choose 'School of Business' and 'Students' which will choose users that satisfy EITHER criterion. So all 'Student' population will be chosen, in addition to users that belong to 'School of Business'.
5. On top choosing/filtering specific group of users to share with, there was also a need to specify View-only or Edit access.

The rationale for an empty Share Settings page is to educate users that there are 2 levels to sharing (I will explain the levels in a bit). So by clicking '+ Add group', a page for selecting users will show. In this 'Select Users' page, users will need to fill in the first box (there is a second box because I skipped a step and showed the state after clicking '+ Add'). By default, the radio button will pick the 'ANY' condition which is probably more commonly used.

So this is where the 3rd requirement is shown in the UI -- To choose Students from the School of Business, you have to do the following:

1. Select the second radio-button option 'Match with ALL of the following attribute(s)'
2. Type/select the two attributes 'School of Business' and 'Students'

So how will users know what they will be doing here? One important and useful way we can help users validate what they have done is by showing a counter (the number of users selected). Imagine typing 'School of Business' first. The count will show maybe 5,000 users. Then right after you add in the second attribute 'Students', the number dips to 687. Since the number drops, users can have a sense that he/she is filtering and selecting a smaller group of users as a result.

In the second screen above, you can see 2 groups, one with 'ALL' and one with 'ANY' selected. So at this point, I felt it was essential to show the number of people this file will be shared with by including both the count and the access rights in the button 'Share with 774 users (view-only)' (See iteration 2 below). This bottom modal will be sticky and visible at all times.

At this point of time, you might be thinking, "how do I specify different access rights for the different groups of users?" This brings us back to the first screen that shows the empty Share Settings page. Upon sharing, the user will be brought back to the 'Share Settings' page that reflect the groups of users they have shared the file with. Since this first group has only view-only access, you can create another group which can have a different access right. (See iteration 2 below). This would solve the 5th requirement.

The subsequent screens simply show how the file detail modal would look like once it is shared, and how it will look in the grid (a group icon is shown next to a shared file).

This particular set of user flow was experimented and iterated three times and I took inspiration from numerous sources such as HubSpot and Google Drive just to name a few. I did a casual test of this flow with my co-workers from Reassemble as well as my friends to ensure that everyone can understand and select the right users to share the file with. Thanks to Sketch prototyping and its Cloud document integration, it was easy to open up the document on sketch.cloud and conduct the test adhoc.

Iteration 2 With regards to sharing, sBox has pointed out to me that their business requirements have changed. Instead of allowing all users to share individual files or folders, there will be a set folder structure in place created by their client's admins, with each folder having different access. Imagine that you belong to a particular department. You will have access to that department's files, as well as your own files and folders (if you choose to share them). Therefore, only folders can be shared now, and individual files can only be shared by sharing the folder containing it.

Furthermore, since there are up to 2 groups of users to share with, users in the Sharing Settings page will select users from either the "Edit" or "View-only" groups or both.

Lastly, sBox pointed out that the final count of the number of users may not be a simple addition equation. Since one user may belong to multiple selected groups, the total number may not be accurate and this value might confuse users. Thus, it was taken out.

C) Select Flow

The 'Select' button was a bit of an experiment. Due to the size constraint, I used an icon without any text and many people could not find the select button. As a result, I took inspiration from Apple and simply use a text button 'Select'.

D) Upload Flow

Since the client has indicated that file uploads can be asynchronous, I did a similar UI as the file clipboard snacker which can be expanded to show the upload progress of file(s).

Desktop UI

Since this application will be developed on React-Native, there will also be an Electron version for desktops.

Nested Pages

For forms, or any page that is not the home page, I've decided to fit the width at 600px. So pages like login, share settings and other nested pages will have similar UI to the mobile counterpart.

Filesystem Page with Context Menu & Detail Sidebar

I've chosen to use a left-sidebar that is similar to Google Drive, allowing users to select folders and subfolders. Moreover, instead of a modal with both actions and details, right clicking on any file will show an action-only context menu. When View Details is clicked, the right sidebar will show the details of the file, similar to how the modal would look like on mobile.

For responsiveness, I figured both side sidebars will be of fixed width, with the centre grid/list of files responsive. sBox has pointed out that if the right sidebar forces a grid reflow, it might disrupt the arrangement of the files, especially the selected file. I couldn't agree more and changed the right sidebar to an overlay.

Furthermore, as an added bonus, some mobile screens which are full width might appear as a modal on desktops to maintain the context of the action (see last screen).

Conclusion

The main takeaway I learnt from doing this project was no doubt the Sharing Settings page; quick iterations and casual tests were essential as I learnt more about structuring content.