Dropbox for Business 3.0

2018

Overview

What is Dropbox for Business 3.0?

Dropbox for business 3.0/CDM is a reimagining of the Dropbox for Business filesystem experience to centralize content and it’s management through differentiated spaces. 

Imagine that:

1. Instead of making groups and assigning folders to those groups, by default your whole company could share content with everyone (team folders in the team space), and then have file folders associated with smaller groups or limited access (confidential folders). 

2. Employees at your company could also have their special place to put their content (member folder) that’s not necessarily tied to a department or their work, such as HR forms or miscellaneous work, with the ability to shared with smaller more specific audiences (shared folders).

It’s like if everyone had one unified Dropbox space, but also their own space.

Why does this matter? 

This allows everyone on the team or company’s dropbox setup to have the same view of all of the company’s content, file-paths, and namespaces, as well as a better understanding of how content might best be organized and placed. This reduces friction from sharing content by making it easier to share to with everyone by default in the team space. It also makes it easier for admins to manage access or create file folder structures that mimic their organization’s workflows. 

This model also reinterprets the file server experience, which is the industry standard for many corporations today and offer security and organization, but not sharing outside of the company.

What was Dropbox for Business like before? 

File organization and management earliest version of Dropbox for Business (~2013) was distinguished by having shared folders and admin controls. This worked as an easy means of sharing content and collaborating in small teams, but there wasn’t an easy way to share content with everyone at scale.

As themes of centralizing content and file organization were becoming more of a focus, the DfB 2.0 (aka GoldenGate), the version that many teams still use to this day, introduced Team Folders, where admins could now create groups within their organization and assign folder access to those groups.

An organization could now have a folder that everyone has access, where each member could add content to the folder and have that automatically shared with everyone, while having shared folders with more restrictions of access through groups. Additionally, personal accounts could be linked with business accounts to more easily manage accounts. However, adoption of Team Folders was low, despite teams having one by default — users ask for  the benefits of team folders, but often don’t know about the feature or how to the difference between shared folders and team folders. 

In short, Dropbox for Business 3.0 / CDM is an investment on the hypothesis that by treating the root space as a centralized home for all of the team's content (team space / TSD), shared with everyone by default like a team folder, then admins will have an easier time managing content permissions and setting up file structures, while team members will be able to flexibly share, understand what content they access to or not, and add content. 

As in the example above, an organization using CDM could have folders organized by department with varying access permissions, while. everyone has an idea of where they might find certain content.

A team member might have private content or content shared with a varied group in their member folder (folder with their name). 

Goals

Our #1 company is to drive team file adoption, where collaboration file folder usage leads to higher team retention in Dropbox for Business. CDM is seen as big effort towards this goal, through a variety of efforts involving driving team activation (teams adding content to the team space), rollouts (beta waves and now all new teams), migration (existing teams moving from DfB 2.0 to CDM), and product quality improvements (for CDM, but also to existing teams on DfB 2.0).

Problems and Opportunities for CDM

In creating this new model where there’s a team space as the root for centralizing content and a member folder unique to each user, we had to:

1. Think about how to adjust our system to support this new model

2. Consider whether our features could also be improvements to the non-migrated 2.0 experience (as we’re rolling out) 

3. Consider how this new experience works in conjunction with other SKUs and users on older versions of Dropbox for Business.

The areas that I focused on for Dropbox for Business 3.0 were: 

1. How might we think about content sharing and receipt to work in this world?

2. How might we reduce friction for users to move content across ownership boundaries in this new model?

3. How might we help users to distinguish between folder types and other nuances of this new environment? 

The complexity of these areas for opportunity was fairly large. Often the problem space would be more than just a problem, but a series of problems, some of which were symptomatic of larger core problems. This involved a lot of product thinking and problem framing to scope solutions with the thought that some problems might not be able to be 100% solved in one shot/might best be addressed through iterative design. 

Area 1  - How might we think about content sharing and receipt to work in this world?

The existing share and receive experience did not work in a CDM world — simply porting over the alpha teams was confusing and threatened the success of teams using CDM. My primary goal in this area was to update the existing CDM share/receive experience (including flows, modals, copy, etc.) in order to update the user experience for CDM  and to ensure the groundwork we lay will support larger teams in the future.

Problem Analysis:

With the introduction of Team Space and Member folder, we found that users fundamentally understand them differently than how they actually work.

The reason for this misconception is due to* 

1. The TSD & TMF spaces are not different at the feature level but at the conceptual level(bothcan contain shared and private content). 

2. The TMF is named after the user’s name. The folder name, “ConorWoods”, makes them think that “the stuff inside it is mine” and disregard the nuances in the actual implementation.

*as observed in Inbound Sharing Insights research participants

Although the misconceptions are problematic, it’s the result of our strategic bet made for CDM. 

Out of Scope

• In keeping with the existing product direction, we will not revisit the TSD/TMF model in this project and instead address the specific usability problems when they occur. 

• Although users may be looking to us for guidance for how to use TSD/TMF appropriately, or when to create a confidential folder vs sharing in TMF, in this project, we’ll focus on the problems in the existing sharing and receive flow only.

• The changes won’t impactgeneralsharing. We’ll bubble up general sharing problems and suggest ideas to the sharing team.

In Scope:

Here’s how the existing system of share and receive worked:

• web

• desktop

• email

Several problems exist from end to end in this member folder workflow diagram

For TSD folder sharing, CDM specific problems are on the receiving side 

Our five problems below, ordered by priority, were:

1. Recipients can’t find shared content in the team member folder

From research, we learnt that users do not expect this and do not consider where inbound shares from off-team members will be placed. 

If users cannot find content in the member folder later, they won’t use the member folder and may result in decreased user satisfaction with our product. 

e.g. If you have a messy desk, you likely won’t go back to find notes in it.

Cause of problem

• General sharing problem?  No.

• Is it caused by CDM?  Yes. 

• Is it caused by the misunderstanding of TSD/TMF nuances?  Yes

Potential solutions

Potential solutions can range from creating more intuitive destinations for shared content in the member folder to more explicitly highlighting the destination of shared content. See more 

2. Users can’t find shared content deep inside of the team space.  

From research, we observed that recipients care about retrieval, but not the process — having to remember parent folders in relation to the content. 

“I'm after the docs, not the process." Link to Brainstorm Retro 

For example, I received a confidential folder (a folder with limited members), but I need to traverse through other folders to access it.

If users have difficulty remembering parent folders, they will have difficulty finding content and seek alternatives to Dropbox. 

Cause of problem

• Is this also a General sharing problem? Yes, but we feel it is important to prioritize this in our project.

• Is this caused by CDM? No, but exacerbated by TSD sharing.

• Is it caused by the misunderstanding of TSD/TMF nuances? No.

Potential Solutions

Potential solutions can range from surfacing file paths in a variety of surfaces to providing shortcuts to get to the content (tab in system notification tray for shared content)

3.  Recipients are confused as to why they can’t move shared folders they receive to the TSD

From research, we saw that although we do communicate this limitation upon failure, users aren’t educated early enough. 

E.g. a user assuming they can move a shared folder from the TMF to the TSD, only to fail at the operation and see a a message stating that they are not the owner.

If recipients aren’t aware of move limitations, they will experience failures, assume that they can’t move anything at all and continue to just work in the member folder, which would be against the goals of CDM. 

Cause of problem

• Is this a general sharing problem? Yes, with TSD to TSD moves by non-owners.

• Is this caused by CDM?  CDM exacerbates the problem.

• Is it caused by the misunderstanding of TSD/TMF nuances? Yes. 

Potential solutions

Potential solutions vary from improving language and clarity in messaging to first time receive onboarding.

4. Recipients believe that they’re receiving copies in the TMF.

From research, we learnt that recipients expected to have full control over shared folders added to the member folder and were confused that these folders were still shared and that other members were still owners.

“Is this a copy and not the actual shared folder?”- Molly

“I assume this is a one way share, because it is in my personal folder. That's what's tripping me up. Because it landed in my personal folder, I'm assuming it's just mine, no one else can ...[make changes] unless I choose”- Ronan

If recipients think that all shared content added to their member folders are copies, they will treat shared content inappropriately — massive edits and deletions without regard for shared folder members, leading to uncomfortable team interactions, workflow disruptions, and lost or disorganized files.

Cause of problem

• Is this also a general sharing problem? Partly — ownership understanding is a general sharing problem, but our CDM experience exacerbates it.

• Is this caused by CDM? Yes 

• Is it caused by the misunderstanding of TSD/TMF nuances?  Yes 

Potential solutions

Potential solutions here vary from user education and onboarding, clearer language in receive notifications, to clearer distinctions between shared and not shared content.

5.  Users don’t feel comfortable sharing from the TMF

From research, we saw that users were concerned that doing so from the TMF would compromise the visibility of the entire TMF. 

e.g. “It’s my personal area, why?” 

If users don’t feel comfortable sharing from the member folder, they will be avoidant of off team sharing and may seek alternatives to CDM Dropbox. 

Cause of problem

• Is this a general sharing problem? Partly. This fear does exist in non-CDM Dropbox. 

• Is this caused by CDM? Yes. CDM exacerbates an existing fear.

• Is it caused by the misunderstanding of TSD/TMF nuances? Yes

Potential solutions

• Solutions from Problem 1

• Focusing on distinction between shared content and private content in the TMF, will hopefully address this.

Area 2 - How might we reduce friction for users to move content across ownership boundaries in this new model?

Our key success metric for CDM is the team activation rate, which is defined as:

1. Teams that have at least 1 file in their team space (TSD)

2. And have at least 2 activated members

Criteria #1 is very important because putting the team’s content in TSD is the most effective way for the team to experience the benefits of CDM.

However, users are always blocked from moving shared folders that they don’t own from their member folder into the team space. 

This is also an issue in Dropbox 2.0 (GoldenGate), where the users moving shared folders they don't own into team folders.

This is important because: 

1. Team folder usage → Higher team retention

This is why the #1 company goal for this year is “Drive team file adoption.” 

The GSA-approved metric for team activation is composed of users linking desktop clients and adding at least one file to a team folder.The proposal linked higher trial conversion and retention to team folder usage — specifically excluding normal shared folder usage!This observation is likely to apply to CDM as well since the team space in CDM is even more prominent than the team folders in Golden Gate.

2. Many new CDM teams already have shared folders

An onboarding research study showed that 70% of new Dropbox Business accounts are upgraded from personal Dropbox. Most of these accounts would(couldverify) have shared folders. Even for teams that do use team folders, analytics show that most of their content are still in shared folders. Since shared folder only has 1 owner and many members, a user would already have some shared folders owned by others.

3. GG users have filed dozens of tickets about this already

CX team has a support macro for this problem, which has been used ~70 times in the last 6 months. While the total number of GG teams is much larger (>244,000 teams as of Sept 24th) , for every user who reported the problem, there are many more who experienced the problem.

4. The problem impacts all current & future Dropbox teams

GG — users who move Shared Folders into the team folder are experiencing this problem today

CDM — both new and existing teams may have shared folders they are already using that they would want to move to the team space

So...what is shared folder ownership?

Here’s the description of shared folder owner from the Help Center article:

The creator of a shared folder is automatically designated the owner. Owners have extra administrative functions, such as the ability to transfer ownership, remove members, and determine whether anyone else can invite people to the folder. 

This means that the owner is both the owner in the legal sense (eg.can recover lost data) and has the management responsibilities (eg. policy setting and immunity to being kicked off). This concept applies to shared folders in Personal and Pro Dropbox skua. 

But in Dropbox Business, while this concept appears to be true for a shared folder in the home folder, all content is actually owned by the team and managed by the group of Dropbox admins via content manager. The mismatch between user expectation and product behavior created a host of issues. 

To correct this ownership confusion, the team space in CDM is designed to be explicitly owned by the team. This means that, as a user moves content with the old ownership model in member folder over to the team space (which is owned by the team), they are implicitly transferring the ownership of the content from an individual to the team. 

Problem Analysis:

This issue is a symptom of the nuances of our ownership model and conflicting user expectations. This affects everyone in Dropbox teams.

As a team, we weren't yet ready to invest in a redesigned ownership model because of the how sensitive our ownership model is and how expensive such a move would be. 

To assess where we could consider improvements and scoping, I worked with my team and design lead to align on our priority for audiences and system use cases.   

Audiences

Use cases (based on our system logic)

In-scope use cases

1. When the users are blocked from moving shared folders that they don’t own from their member folder into the team space, they see the message that they can’t move the folder into the team space because they aren’t the folder’s owner. 

A. Users are not provided with any action or advice to resolve the problem.

• Who is the folder’s owner? 

• How do they request the owner to move the folder? 

• Do they have to obtain the folder’s ownership to move it? How do they do that?

"I have several files & folders in my personal area that have been there for some time. I have tried to move them but it says only the owner can move them. One directory in particular, "01051Inspection 140423" , has this problem. I went into the admin console to see about the owner and if I could move the files from that area. No luck."

- Dropbox admin from Aspen Management (from early beta pilot team)

B. Even when the user does know who is the owner, the manual process of pinging the owner to move a Dropbox folder can still be a frustrating experience.

"Is there a way to move items that were made by other users? It’s irritating to have to go and contact the CEO to do this."

- Dropbox admin from A&D Medical 

This quote is from one of our most engaged pilot teams. Even though CDM serves her team’s use case perfectly, the folder transfer friction is enough to prevent her from moving a handful of folders.

2. The shared folder is owned by someone from another team or by a person from their personal account. 

The owner may not want to transfer her/his ownership over to another team, but when the content is a result of a collaboration between multiple teams/organizations, who or what team has the right to this content?

Our original assumption was that most of the time the moved shared folders that are owned by the user or by existing team members and ruled this to bean out of scope problem. 

However, once we got better analytics, we found that the opposite was true, that as much as 60% of the time, the shared folder is owned by an off team member of someone not on a team. This is likely due to the fact that many small business teams have fragmented Dropbox licenses (some personal and some as Dropbox for Business team licenses).

Out of scope use cases

3. The admin is moving a shared folder with several external members that should/could be on the team. This could be the case for admins who just upgraded their account with existing sharing relationships with her/his team members.

We might want to look into this problem later. However, since the considerations involved in adding new team members are more complicated: involving licensing and the admin’s understanding of the differences between adding people to shared folder access permissions vs to the team, we won’t be addressing it in this shorter-term project.

4. We let non-team members move shared folders they own into a team space without warning and disallow the reverse move. This can lead to owners accidentally transferring content to a team, even a team they are not a member of, with no obvious recourse.

5. Transferring ownership from a team to an individual member isn't possible in CDM.

Once a folder is in a team space, it can only be removed by a team admin by the following steps: 

1. giving themselves access to the containing folder

2. moving the folder to their home

3. and then transferring ownership to the desired account.

This flow is only possible in Dropbox for Business 2.0 / GoldenGate's team folders. Furthermore, step 2 is blocked if the move would create a deeply nested share.

6. Team to team transfers are practically impossible.  

It can be done, though by going through the flow from use case 5, then use case 4:

• admin transfers to self as individual

• admin transfers to other user on other team with“makeowner”

• other user transfers from self to their team

Goal

For this area, l focused on addressing use cases 1 and 2 with relatively low engineering cost to get short-term improvements on the move experience. In addition, conducting research and data analysis on the larger content ownership and ownership boundary problems to address them later.

Area 3 - How might we help users to distinguish between folder types and other nuances of this new environment? 

A major area of concern for CDM is how well we can communicate nuances, such as which spaces are team owned and not. This also bleeds into other areas, such as those discussed above (sharing and ownership). 

By September 2017, CDM had been released to 500 small business trial teams. In the initial rollouts, there were a few problems resulting from largely keeping iconography from Dropbox Business 2.0/GoldenGate, where the CDM folder hierarchy becomes  unclear. 

• The briefcase icon used to represent Dropbox Business Files across platforms,  a metaphor of bringing your briefcase to work, is inconsistent with the core CDM  concept of getting access to work content from a centralized repository.

•  Shared folders from Team Space and Member look exactly the same and both called shared folders.

  • This similarity makes it hard to communicate the differences between content in TSD and TMF.

  • As well as adding to difficulty for users to communicate the destination of a shared folder in the member folder.

We saw changing the iconography of folders in CDM as a viable path for presenting the new file structure in a clear and consistent way.  

We also saw iconography as a way of aligning the system to the user expectations in Dropbox for Business: 

• communicating to all users what is

  • Shared

  • Read only

  • Not shared (only the user)

  • Confidential (everyone, but the user)

  • Team Content

Differentiation through iconography, could also be an area that helps us to brand and market CDM as a new Dropbox for Business offering.

Designing CDM Share and Receive

The earliest consideration I had was to consider a phased solution approach for improving share and receive, where I imagined ways that we could prioritize and invest in particular sets of problems iteratively and not mitigate risk:

M1

Goal: 

Improve and update the fundamental share and receive experience of CDM particularly through the following areas  

1. How recipients are able to rediscover shared content

2. How we communicate move ability to recipients

Problems to be addressed:

The following problems were selected based on receiving experience priorities.

• Problem 1 - Recipients can’t find shared content in the member folder

• Problem 2 - Users can’t find shared content deep inside the TSD

• Problem 3 - Recipients are confused as to why they can’t move shared folders they receive to the TSD

Solution space:

We’re looking to explore short term email improvements, while exploring solutions such as improvements to notifications and shortcuts to shared content. 

Research questions in this phase:

1. How does our solution aid in our confidence for handling dependencies from other Dropbox surface areas like Recents, /deleted_files, /events, etc?

2. How might our solutions affect“downgradeto free team” behavior?

3. Will our solutions mitigate risk and ensure confidence in confidential folder behaviors(maintaining explicit policies on moves, behavior copying a tree with Confidential Folders) and visibility (showing Confidential Folders, showing their names)?

M2

Goals:

Improving comprehension for recipients and reducing friction for sharers

Problems to be addressed:

We selected the following problem based on prioritizing retrieval scenarios in this phase.

• Problem 4 -  Recipients believe that they’re receiving copies in the TMF

• Problem 5 - Users don’t feel comfortable sharing from the TMF

Solution space:

We’re hoping to explore long term email improvements here as well as previews for senders(helping senders know what the recipients will have access to). 

Potential metrics:

• Quantitative metrics likely around CX tickets regarding receive experience, web session time in share flow, /share v. search activity

• CX satisfaction measures regarding discovery for recipient and ACLs from sender to recipient)

M3

1. In coordination with the Projects team, creating collaborative spaces, such as TSDs between Companies

   1. e.g. a shared drive between Acme and Nike(Acme<> Nike)

2. Increased role of Paper in communication nuances around sharing contexts and purposes

   1. Paper taking precedent over having to share a file or folder for review / view only purposes

3. Dynamically generated contextual folder bookmarks

In line with this solution strategy, I started ideating for the M1 phase and it's solution space.

Thinking about user goals for Share/Receive

The user goals that we’re being mindful of in our solutions are the following:

• As a user, I want to get the content just shared to me

• As a user, I want to know where content I “receive” will go

• As a user, I want to be able to find content without heavy recall

Much confusion comes from the act of receiving because it was unclear the difference being shared a folder in the team space and a shared folder that needs to be mounted to your member folder. 

Current Desktop Experience:

1. In the current desktop experience, a user who get’s shared a folder will get a desktop notification with the action of “Add to member folder”

2. Additionally, the recipient gets a receipt email with a CTA of “Go to folder” that opens the web experience.

Current Web Expeience:

1. If the recipient is given a link rather than invited to the shared content , they’ll land on a preview page with a Download cta.

2. If the recipient is on web and receives an invite, they’ll see a toast with the option to add the content to the member folder or preview it (taking then to the preview screen). In some instances, previewing isn’t an option.

Adding the folder on web looks takes the user to the content of the folder, now in the member folder.

Ideations and explorations for Share/Receive

Far out

One early idea was considering the possibility of having a special folder either in the root or in the member folder to:

• Help users to distinguish between team shared content in the team space and that which would be off team and go to the member folder 

• Develop an expectation for where off team shared content would go if they receive content. 

We decided against this route because: 

• would be expensive to build

  •  requires a large change to the dropbox model

  • making a unique "Shared With Me" folder in the root for all users is complex due to file path uniqueness 

• product principles

  • trying to move away from special folders

No so far out

Another area that I explored was means for helping users to navigate types of shared content through ui and shortcuts. 

• Having a tab in system tray for items recently shared to you  / corresponding path on web

• /Home as path to shared content in member folder

• Having separate lists for starred folders and folders shared with you in /home

The main con here is the additional coordination and effort with the home page team and the notification team  required of this  redesign effort.  

Near

1. Considering short term communication improvements

Trying to balance the goal of quickly getting content, while having some clarity and transparency of what’s happening -- what sort of content was shared, where it can be found in the filesystem, whether the user has to mount the folder, and perhaps what permissions they have for it. 

Some thoughts I had around this were exploring changes to email subjects, body text, showing file paths, and differentiating between shared folders that need to be mounted to the member folder v. those which the user is given access to in the team space that are automatically mounted. 

Language offered a variety of means for differentiation between team space shared folders and member folder shared folders.

• "Invited" vs. "wants you to see"  could communicate the fact that you already have access to the content in the team space v. having to add it

• Showing path vs. calling out that you to add it to the member folder

Another concept I explored with my ux writing partner was how we might communicate permissions and access types and how explicit to be. 

Would communicating how to get other access abilities help?

Could emoji's add to comprehension of access types (edit, view only)? 

Should we consider new verbs to map to  access  types (view only -> "review")?

The main limitation here was that in considering the whole system and other Dropbox for Business skus, we don't want to have our emails be too divergent. We also wanted to leave room for a possible email redesign further ahead.

 2. Investments in user education

Education and making Member folder nuances obvious.

• Help center article and Learn More links  

• A First Time Receive Onboarding

The biggest problem with this approach were that our onboarding infrastructure couldn't support dynamic content such as folder names or highlighting folders in a specific row or section of the site.  Additionally, no onboarding experiences existed in our desktop platform at the time. 

3. Helping users to better decide if they want to mount shared folders in their member folder

Having recipients preview before adding as a default on web and accessible via link on desktop notification

e.g.I’m shared something, but don’t want to put it in the TMF…yet

Converging on ideal solutions for Share / Receive

Since that our core problems in this phase was to address that

From user testing, we saw: 

1. recipients had difficulty finding shared content in the member folder

2. recipients had difficulty finding shared content deep inside of the TSD

3. recipients were confused about move limitations of content they received 

Due to:

1. “Add to Dropbox” CTAs and pre-CDM Dropbox language not matching CDM contexts

2. No mention of where content can be found and whether it’s TMF or TSD content

3. No direct means to getting education in the sharing user experience

My recommendations from converging on solutions were:

• Updating language across CTAs and surfaces to make member folder and TSD sharing clear and distinguishable 

• Education of CDM sharing concepts through learn more links, help center article, and first time receive messaging

• Showing paths for TSD sharing in receive emails and notifications

Where scoping for web, desktop, and mobile was:

• new notifications

• additional links

• a new help center article

What were the proposed changes?

Imagine your coworker, Belle Lin, shares two shared folders to you that you can edit:

• Offsite Pics, which should be added to your member folder

• Q3 Planning docs, which is within the Marketing folder in your TSD.

What does this look like at a component level in the current shared folder experience v. what’s being proposed for TMF and TSD sharing? 

Imagine if Belle shared these same two shared folders with you, but she only gave you view access:

What did this proposal look like on a systems level?

TMF shared folder (edit) flow diagram → 

TMF shared folder (view only) flow diagram →

TSD shared folder (edit) flow diagram →

TSD shared folder (view only) flow diagram →

Usability 

The big questions we had versus the proposed designs assumptions were:

• Are there areas of confusion for the participant?

  • Do people understand the term“memberfolder”?

  • Whether recipients understand where the shared content can be found

• How clear is it to recipients that they have to mount member folder shared folders

• Can a recipient accept a shared folder?

• Can a recipient identify how to get help?

  • Do they know where to look?

  • Was it hard/not hard?

We found remote usability research through usertesting.com to be an effective and not too expensive means of answering these questions. 

I collaborated with our researcher and ux writer to conduct two studies featuring our email to web flows and desktop experiences.

In both studies, users were tasked with accessing content in a folder shared to them, with variations on type of access to the content, with the following workflows and user goals:

1. A user receives a shared folder to be mounted in the member folder (TMF edit or view only)

Goal: Successfully add the folder to the member folder

2. A user gets view or edit access to a shared folder in the team space (TSD edit or view only) 

Goal: Successfully get to the folder in folder in TSD

3. Have users identify where the folder they received is from an open top level Dropbox folder

Goal: Users are able to successfully identify where the folders they received are from looking at a top level folder presentation.

Email to web prototypes

TMF View Only →

TSD Edit Access →

Top Level Folder View → 

Desktop (Windows 10) prototypes

TMF Edit Prototype →

TSD View Prototype →

Top level Folder Prototype → 

From these studies we observed that: 

Our solutions did not cause confusion or disruption from the user goal of getting to the content and provided basic means for users to rediscover content. 

The entry experience fit in line with how users would naturally navigate. Given our scope, we couldn’t do much more in the email and entry experience for touching on folder location. One future term suggestion is visual differentiation, such as a purple CTA for member folder sharing contexts.

However, for the rediscovery case, we should consider more prominent surfaces for future improvements out of this scope, such as proposed in the early notification and home explorations. This research would serve the retrieval team and other’s initiatives focused specifically on retrieval.

End Designs and shipping CDM Share & Receive M1

Adjustments to spec from research for the short term, for our scope, recommendations were:

• Be conservative in using the term“memberfolder” — it’s too ambiguous for users to understand(theythink it refers to the entire Dropbox). 

  • Member folder should refer to the concept and folder type, but not the actual folder itself. This along with changing the language in CTA to“[Recipient/memberfolder name] folder” or something along things lines would be explicit enough to specifically call attention to which folder. 

    • e.g. in email

      • “To get started, add this to your member folder.” [ Add to Chris Grant folder]

The end designs reflect priorities of

1. Email Updates

2. TSD notification changes

3. Help Center article

4. First Time receive notification

These updates were shipped with our second Beta in the fall and are a part of our current experience for new teams and teams that have migrated into the CDM experience as of March 2018. 

Platforms

• web, native mobile (iOS, Android), desktop 

Primary use cases

• User receiving and mounting a shared folder to the member folder (First time mounting)

  • This is CDM specific

• User receiving and mounting a shared folder to the member folder (future mounts)

  • This is CDM specific

• User receiving a shared folder in the TSD (all times)

  • Relevant to nesting in general sharing

The end design handles these cases through differentiation in language, CTAs, and user flows, as well as use office path for folders located in the team space or nest folders.

Edge Cases to support

Long file paths for TSD receive flows (likelihood- rare for > 4 folders deep)

Being Re-invited

Unmounted shared folders follow the TMF receive flow (first time or following). 

The experience for a recipient that has mounted would follow the TSD sharing flow, where since the folder is already mounted, our CTAs and paths are simply to go to or view the folder, no previewing or mount modal landings.

Flow diagrams

TMF Edit Schematic Flow diagram (web, desktop, email) → 

TSD Edit Schematic Flow diagram (web, desktop, email) → 

TMF View Only Schematic Flow diagram (web, desktop, email) → 

TSD View Schematic Flow diagram (web, desktop, email) → 

Entry

Each of these components in this step are what a recipient will encounter upon being a sender starting a TMF or TSD sharing experience.

Email

Note:

• “Add to member folder” CTAs send the recipient to the pre-mount web experience (/share modal)

• "Preview” CTA sends the recipient to the file previewer experience.

• “Go to folder” CTAs send the recipient to the folder on web

Web

Note:

• clicking “add to member folder” cta will mount the folder

• clicking regions other than the CTAs will send the web browser to the pre-mount experience (TMF) or the folder itself (TSD)

Desktop

Notification Bubbles (persistent)

Note:

• Clicking add will mount the folder and open the shared folder from desktop 

• Clicking view will open the folder from desktop

Tray notifications

Note:

• clicking“add to member folder” cta will mount the folder

• clicking regions other than the CTAs will open the web browser to the pre-mount experience (TMF) or the folder itself (TSD) on desktop

First Time receive (after mounted)

This appears after a recipient has mounted a TMF shared folder for the first time, since converting to CDM. These are new notifications.

Web

Desktop

Note:

• Learn more links lead to help center article

Pre-mount

Recipients arrive here from notifications (non-CTA clicks) or “Add to member folder” CTAs in emails for TMF sharing flows.

Web (/share mount modal)

Note:

• This modal is on /share page 

• Users reach via email or by clicking a web notifications(outsideof the cta region) for TMF sharing

• Learn More links go to Help Center article

• “Add to member folder” CTA mounts the folder and takes user to the folder on web

• “Preview this folder” link send the user to the file previewer

Web (file previewer)

Recipients arrive here via TMF view only email preview link or through the /share mount modal’s preview link.

Note:

• Clicking add to member folder will mount the folder via web. 

• Download gives the recipient a copy

Web file preview (download or save)

Help Center article 

I worked with our customer experience / support team to update our existing help center content.

End (Mounted TMF shared folders) 

The toasts that appear when you mount a shared folder to the TMF.

Web

Desktop

Something that we had to account for was the ability to have online-only and local settings for folders on Dropbox for Business via SmartSync. So our mount notifications on desktop vary in language depending on online only or local.

End (TSD shared folders) 

Since shared folders in the team space are automatically accessible to the user and don't require mounting, I didn't propose anything new for once you've accessed the shared folder.

For Windows 7+

Although desktop mocks are limited to Mac, all interactions, flows, and behaviors are the same for Windows with minor visual nuances. 

i.e.“x”instead of a close button

Mobile (iOS, Android)

I followed our philosophy of keeping mobile apps to the same conventions and flows as web experience for consistency as well as keeping in mind that our mobile app would soon have a redesign and updated design system.

Designing Ownership Transfers and Shared Folder Moves

Following our base product brief and thoughts on scoping, I conducted an audit to document the current places in our product related to moving shared folders across ownership boundaries and highlight areas of improvement. 

Encompassing web, desktop, and mobile platforms,  the user scenarios this audit covered were:

1. A team member and non-owner attempting to move a shared folder to a team space (CDM) or team folder (DfB 2.0).

2. A shared folder owner moving the shared folder to a team space (CDM) or team folder (DfB 2.0).

In doing so, I found language, usability, and consistency issues in the file system warnings and move flows that create stumbling blocks for the non-owner.  

Stumbling blocks for non-owners attempting to move folders

In focusing on reducing frustrations and stumbling blocks in the move experience for non-owners, we, in turn, reduce friction for future move attempt of shared folders across ownership boundaries and encourage more content to be moved to the team space.

On Desktop

The file system warning doesn’t explicitly provide a way to having the folder moved. A learn more link isn’t sufficient.

On Web

There’s nothing calling out to the user that the move destination is illegal.

The confirmation modal could make a non-owner feel that the move is going to succeed. 

The file system warning doesn’t explicitly provide a way to having the folder moved and doesn’t offer support, even through a learn more link. 

On Mobile

Observations from Analytics   

Shortly after this audit, new findings from analytics informed us of a greater need to account for off-team and no-team scenarios, than we’d previous thought.

• In Nov 2017, the FSW was shown 11,466 times (6,221 distinct users, 6,289 distinct hosts)

  • 75% of users that hit the FSW are DfB users, 9% Fastrak (trial business), 9% Plus/Pro, and 7% Basic

• Only 8% of FSWs result in an ownership change, and 5% of FSWs result in a successful move

• FSW is mainly shown to teams users, and in most cases the users had not just joined the team.

• 26% of users hit this FSW more than once, and only 19% hit it more than once for the same shared folder. 

• When this FSW is being shown to teams users, 65% of the time the owner is a basic/pro/plus user. These might not even understand what a team folder is, and why their content needs to be moved. 

  • We need to be cognizant of this because it’s very common for a company to have a Dropbox setup that is fragmented — a mix of team and no team accounts for cost reasons. 

    • This means that the entity representations of teams in our system may not represent real life teams in a company. We also don’t have ways of deeply detecting truly distinct entities. 

• 32% of the FSWs shown were when the owner was on the same team.

There were also findings from a then ongoing sharing email redesign and access request project that were informative as well:

• It takes a long time for people to get their requests approved

  • 30% of all requests are given access within 45min

  • 55% receive access within 24 hours.

  • 60% within 5 days

• A significant portion of approvers aren’t approving or opening the emails

  • 25% of request access emails are never opened.

  • 25% do not click “approve request” button after opening the email

• The team is experimenting with email redesigns and notifications to improve this and currently is seeing a 75% open rate and CTR for an “approve access” link in the request email. 

Point of View

My point of view following was that the stumbling blocks to user goals of moving shared folders to team folders or team spaces are symptoms of a larger root problem of the complexity of our ownership model and how our system communicates it to our users. 

These symptoms exacerbate this root problem of our ownership model by creating and reinforcing perceptions that non-owners have about operations they can perform on shared folders and content they don’t own — particularly non-owners attempting to move shared folders across ownership boundaries. 

Although we'd want to make a better ownership model, that is expensive and far beyond the scope of this project. 

Where we should focus on for now is tackling these particular exacerbations of the ownership model problem — that our current experience of moving a shared folder to the TSD sets the non-owner up for frustration by making them feel that the move attempt will be successful, despite the operation always leading to failure. 

Explorations

Per my point of view, the goal in exploration was that our end solution should offer improved messaging, provide paths to education or resolution of the non-owner’s move intent, and consider off and on team scenarios.

My process of exploration was one where I would start at the lowest fidelity to get a sense of solution complexity and system requirements of such directions from my PM and engineering counterparts, while also using our team design crit sessions for design feedback, that I would consider along the way. 

The divergent solutions I explored were:

• The most obvious — what if we updated the file system warnings to have the owner’s contact information?

• The super intuitive for in-team, but not feasible for off-team — what if we could allow non-owners to send the owner a request to move the shared folder to the team space, and if approved, it’s automatically done? 

• The best tradeoff — what if we updated the file system warnings as well as provided a way for the non-owner to request ownership and then do the move?

What if we just told the non-owner who the owner is and gave them a way to contact them?

This solution was the most obvious and simplest direction we could go, but was it the best for our users?

Non-owner Experience

Adding the owner’s name and email to existing file system warnings.

On mobile and web, this would require adding inline text within the move modal when the TSD location is selected.

Owner Experience

The thought here is that after seeing thee file system warning, the non-owner would reach out to the owner and they would perform the intended move for the non-owner.  

Pros

• providing users with a way to identify and contact the shared folder owner is a positive that can lead to direct resolution without getting deep into ownership concepts 

• the owner doesn’t have to transfer ownership

• No flow changes

• No added emails 

• No added notifications

Cost and complexity

• low

  • this would just be copy changes to include the owner’s email on existing file system warnings and adding inline error messaging to the move modal on web.

Risks and cons 

• For the user

  • non-owners may not be comfortable with directly contacting the shared folder owner outside of the Dropbox environment

  • owners may be annoyed and potentially flooded with emails

  • If the TSD restricts non-team member owners, the requester would have to ask for ownership 

• For our business

  • Although this option would be simplest, better, more intuitive solutions exist that could be a differentiator for teams staying with us or going with another service.

What if the non-owner could get approval for the move to happen and then it does?

A move request sent from the shared folder non-owner to the owner as they attempt a move. Owner gets notified. If approved, move happens and both users are pointed to the new folder destination. 

This direction offers a more intuitive user experience, but is only feasible for in-team move scenarios.

Non-owner Experience

1 - Sending an move request

•       mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

A nice to have here would be the ability to cancel the request.

2 - Move request approved, move happens

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

3 - Move request rejected

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

Owner Experience

1 - Receiving a move request 

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

2 - Approving or declining a move request

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

With the click of a button, the request can be approved or declined. 

• If approves

• If declines

A nice to have here would be the ability to cancel the request and notifications to the shared folder owner in that event.

Pros

• We provide the user with a path to moving the shared folder rather than a dead end

• We can build atop of email and notification resources Grant Access/Request access

• We have data from Grant Access/Request access to inform this solution

• This the most intuitive and sensible experience — get approval and the move happens!

• Owner and non-owner don’t have to think about ownership concepts. 

• This is best serves the case of the owner being on the same team as the non-owner

Cost and complexity

• medium to high

  • Although this experience can reuse and repurpose our existing file system warnings and move modals, and can borrow notifications from Grant/Request Access, we currently don’t have any existing equivalent of a system for approving and executing moves.

  • Significantly complex to build vs. mvp

    • Handling the case of the TSD destination’s location changing is expensive

    • Needs logic for checking if the move is legal for the owner.

Risks and cons 

• For the user

  • Owners could be annoyed by receiving and maintaining move requests

  • Restrictive TSD destinations make this option unavailable to no team and off team owners.

• For our business

  • We may have take on more risks for perceived data loss, communication, and legal concerns associated with content ownership when ownership is transferred. 

What if the non-owner could get ownership and then execute the move?

An ownership transfer initiated by the non-owner sending a request for ownership to the owner, which if the owner approves, gives the non-owner ownership and a path to moving the shared folder. 

This solution is the best tradeoff for supporting move intents regardless of whether an in team and off team scenario.

Non-owner Experience

1 - Sending an ownership request (in the context of move attempts)

•         mobile prototype

•         web prototype

•        desktop prototype

•        email prototype

Non-owners would be able to send ownership requests as a part of their move attempt — whether through dragging a shared folder in their member to the TSD or selecting the TSD destination in the move modal on web or mobile. 

Once a non-owner sends an ownership request, the owner of the shared folder immediately receives an email and cross-platform notifications and the non-owner gets an email confirmation.

A nice to have here would be the ability for the non-owner to cancel their requests. 

2 - Ownership request approved and moves folder

•         mobile prototype

•          web prototype

•     desktop prototype

•        email prototype

3 - Ownership request rejected

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

Owner Experience

1 - Receiving an ownership request

•         mobile prototype

•          web prototype

•     desktop prototype

•        email prototype

Once a non-owner sends an ownership request, the owner of the shared folder immediately receives an email and cross-platform notifications, allowing for the request to be declined or approved. 

2 - Approving or declining an ownership request

•         mobile prototype

•        web prototype

•     desktop prototype

•        email prototype

With the click of a button, the request can be approved or declined. 

• If approves, the owner is informed of the ownership transfer to the non-owner via notification or snackbar and is taken to the folder or can navigate there, while the non-owner gets email and cross-platform notifications of the approved ownership transfer.

• If declines,  the non-owner is sent a decline notification.

• If unsure, the owner can also read a help center article via learn more links.

3 - Cancelled ownership requests (nice to have)

•         mobile prototype

•         web prototype

•     desktop prototype

•        email prototype

Pros

• We provide the user with a path to moving the shared folder rather than a dead end

• We can build atop of email and notification resources from Grant Access / Request access

• We have data from Grant Access / Request inform this solution

• Works independent of whether the owner is on the same team or not

• This solution can also be used as a standalone to support non-move-related use cases.

Cost and complexity

• low

  •  this experience can reuse and repurpose our existing file system warnings, move modals, and engineering can work with the Sharing Team’s Grant Access/Request access efforts including notifications in SP2

Risks and cons 

• For the user

  • Because of logging limitations and differences for tracking intended move destinations on web and desktop, this experience isn’t the most intuitive — users will have to go back to the folder and move it to the intended destination after getting ownership.

  • Users might not want ownership, especially if it’s just to do a move. 

  • Users might be confused by having to get ownership first.  

  • Owners could be annoyed by receiving and maintaining ownership requests

  • Owners may be reluctant to transfer ownership because of risk aversion or level of comfort with having content managed or moved by a different owner

• For our business

  • We may have take on more risks for perceived data loss, communication, and legal concerns associated with content ownership when ownership is transferred, but regardless, this would have the owner’s consent.

User Research

For early validation and insights, I conducted moderated research sessions with actual Dropbox for Business users.  A more in-depth look at that research can be found here.

The goals I had in these sessions were  to walk away with signal on:

1. Comprehension/education: 

   1. Do people understand what the messages mean?

   2. Do they understand what ownership in this context?

   3. Do people understand what is going to happen if they send an ownership request? 

2. Utility

   1. Does requesting ownership make sense? Is it useful?

   2. Will users see contacting or sending requests as helpful

3. Concerns/questions

   1. Will we confuse users here?

   2. Will non-owners feel friction with our FSWs?

Our participants were:

• Biz users

• Collaborative in Dropbox - self reported

  • Collaborate on a shared document or project with someone else

  • Give or receive feedback on documents or projects

  • Share drafts or work-in-progress documents or files

• company < 100

• team < 5

Solutions Tested:

In testing, I was trying to probe user expectations for our File System Warnings, specifically:

•  seeing whether our messaging was resonant or adds friction to the file system warning

•  whether or not our subjects would try to take action from seeing either solution

• whether any preference exists for asking the owner of the shared folder to move the folder or asking for ownership

• what user expectations would exist for any action taken or comms from the system itself

• if our solutions would change how users use Dropbox

#1 Move FSW (basic)

Representing our most mvp proposed solution, in this scenario, the subject tries to move a shared folder (they don’t own) to the team space from their member, sees the file system warning appear, with the owner’s name and email and a suggestion to contact them to do the move.

#2 Move FSW (requesting ownership)

In this test, we explored whether  the concept of asking for ownership would register and what sort of expectations users would have if they were to press a primary action, such as "Ask".

#3 Ownership perspective (email)

In this 3rd test, we probed for what participants would expect to see on the receiving end as the owner of the shared folder — getting a sense of whether users would understand concepts of ownership, what they thing would happen in transferring it to another user, and what friction might exist.

Key Findings

• 75% of participants couldn’t associate the move limitation with ownership

  • thought that the move attempt FSW appeared due to them having view and not edit permissions for the shared folder  

• 100% of participants felt that the non-owner would feel friction upon seeing FSW1. 

• Regarding FSW2, 75% thought “Ask” would send an email or message within dropbox to the owner

• All participants felt that FSW2 was a better experience than FSW1 

  • specifically felt that they were given choices to resolve the issue of the move being blocked  

  • felt language was more direct

• communicating state and what’s happening across platforms was important to our participants — email was not enough

• Thoughts on what would happen if ownership request is approved

  • All participants felt that they’d be able to move the folder if ownership request is approved

  • 2/3 of participants thought that this would lead to there being more than one owner

• 2/3 of the participants would have reservations as the owner receiving the request and they they would need more information before approving

  • fear of loss of access and management

    • coupled w. fear of there only being one owner.

  • fear of the non-owner’s intention for the move and whether it is conflicting with current dropbox structure

• All participants found value in FSW 2 and found FSW1 to be an unsatisfactory experience that would also make them not attempt a move again. 

Impact on End Design and Strategy 

The above research findings lead me to the following recommendations and decisions:

1.  We should invest in our ownership transfer flow (FSW 2) as a first phase rather than the short-term fix of only copy updates to FSWs (FSW 1)

2. Copy adjustments to be more explicit in actions, why non-owner can’t move folder, and for communicating intent of request to the owner and repercussions to the owner  (see Usability Items in table above)

3. Definitely providing a way of finding who the owner is if not able to show that in FSW

4. Being communicative of state of requests and actions associated across surface areas (observed a need for notifications over just email)

End Design Proposal - Shared Folder Ownership Transfers and Move Requests

A more in depth view of the end proposal can be found here.

In line with our research findings, I recommended a phased solution approach, where:

First — an ownership request experience triggered from the non-owner’s move attempt w. updated file system warnings, notifications, and emails for non-owners and owners.

• testing the hypothesis that providing language improvements, the owner’s contact information, and an experience to send an ownership request in product would be sufficient means for the non-owner’s goal of moving the shared folder to the team space. 

• Note: Our primary focus in this phase is shared folder ownership transfers in the context of moves, but we’ll also have a means for users to request ownership outside of this context (e.g. surface areas other than the file system warning)

Second — At a later stage, move requests as the default for in-team move scenarios + ownership transfers as default for off-team move scenarios

• Providing the most intuitive experience available for our move scenarios

Designing CDM Iconography Updates

This was a fairly large design driven initiative involving the CDM team, our design systems team, web, mobile, and desktop client engineering teams.  

This was a collaborative effort between another designer and myself -- where following explorations and audits, my role was to design the new icons and update our existing CDM icon designs across all Dropbox clients, platforms, and surface areas as well as provide input into roll out plans.

I saw this as a neat opportunity to do more visual design as well as thinking about graceful degradation across platforms and seeing how Dropbox is able to strategize and make solutions work in an ever changing operating system environment.  

Considerations  

For this effort we had to consider the following and how our existing iconography communicates these concepts as well as platform specific nuances: 

1. Folder Types -  Is the folder shared with more people or private just to me?

Outside of team space and team folders:

•  The private and shared folder icons are not used to indicate the folder’s audience.

• The shared folder icon is used to indicate the folder has been explicitly shared with other people.

• A folder inside it can be shared with the same people yet appears as a private folder.

• If the user removes all other people from the shared folder, the iconography doesn’t change even though the folder is no longer shared.

• Inside team space  & team folders:

 All folders should use the shared folder icon to indicate that they are in a shared space. With two different  rules to display folder icons, it’s impossible for users to understand the what the folder icons really mean across the product.

2. Access levels -  What level of access do I have?

• Editable shared folder

• Read-only shared folder

• Restricted folder: this folder icon is only visible when you don’t have access to the content

3.  Sync status - Is the folder available locally or only on the cloud?

4.  Liveness State (active/deleted/archived)

5. Special Folders

• Dropbox folder

• Public folder

• Camera Uploads

• App folder

6. Surface Areas

 Offline folder (mobile)

• All content is on the cloud by default

• The user can download specific folders to access offline later

Web breadcrumbs

•  We didn't use the briefcase icon to represent Dropbox Business product consistently. This made use question if  we use the building icon instead?

• The NewTeam Team Folder  should use the shared folder icon

 Web browse

On web, the design systems team had gone from this icon set for folders:

•  Member folder is pinned on top and has an unique icon (new)

• The restricted folder names uses a lighter text color (new)

To this set:

Mac OS specific views:

Windows OS Specific views:

Move Modals (Web and Mobile)

Existing Research

 To keep ourselves grounded in the realities of everyday usage, here’s the real (give or take) user behaviors and mindsets related to folder icons:

1.  Users expect visible differences  when upgrading from Personal to Business that reflect their goal of getting everyone on the same page. 

2. The folder icons are too small  and many users don’t notice the differences. So icons shouldn’t be viewed  as the primary way to convey permission information.  If we do want to convey information visually, then  it needs to be prominently displayed.

3.  In June 2016, we decided on the badge everywhere (using shared folder icon to indicate that the folder is accessible to multiple people) to highlight the difference between shared vs private content. The rationale was to prevent against negative consequences of ignoring or misunderstanding the icons.

Explorations

In exploring, we were thinking of what changes to make to the iconography we had that would address the following use cases and problem areas:

The main approaches to the solution space were: 

• Using folder iconography to update the folder hierarchy

• Refining folder iconography to better communicate access (confidential or read only)

• Establishing principles for icon use

Folder Hierarchy Explorations

Extreme differentiation member folder content and team level content through color and icons

1A. Using purple for all member folder content, blue for team space folders, and building icons for folders in the team space.

The good:

•  The most obvious way to visually differentiate between shared folder from team space or member folder

The not so good:

•  This color hierarchy seems more complicated than necessary

1B. Shared folders in the team space are purple and team folders use building icons instead of shared folders, while the member folder and contents are blue.

2. No color changes, but relying on the extended concept of team folders as a way to differentiate between team space content and member folder content at both top and nested levels.

3. No color changes, but relying on the extended concept of team folders as a way to differentiate between team space content and member folder content at only the top folder level.

4. Using only color to differentiate between shared folders and content in team spaces v. member folders

Here's the idea is that users would be able to tell if a shared folder s in the team space or member folder by whether it is blue or purple.

5. Using color as an indicator of shared or private content

Where a user would know if content is private based on whether the folder is purple or not, where shared folders would always be blue.

Explorations to consider ways of communicating access level associated with shared content

In these explorations, we were thinking about ways that we could communicate whether shared content as read only or confidential.  

It's important to communicate these access levels so that our users can understand why they can't edit or execute certain actions to the shared content, such as the case with read only access, or that although a shared folder exists in the team space, the user does not have permission to access (confidential).  

Our primary thoughts were to consider to a minus and lock as indicators:

•  The concept of using a lock seemed natural to us as locks are metaphors in most operating systems for read only folders and content.

• Minus is also a commonly used pattern for restricted access in operating systems. 

Direction 1 - indicating access type through the main folder icon

The idea that perhaps indicating most prominently is the best path. 

A problem with this direction is that it wouldn't be as clear to the user that the ready only or confidential folders are shared content. Additionally, Mac OS applies a lock to read only folders, so this design would  seem redundant.

Direction 2 - using the main illustration zone to communicate both shared status of the folder and the access level for the user.

This brings us closer to visual consistency with our other folders, but still raised concerns for translation on desktop platforms.

Direction 3 - Separate Approaches for Ready Only and Confidential Access folders

Since the main compatibility issues for desktop platforms is the application of a lock to our folders for read only access.

We felt that the best compromise would be to consider the read only folder as a whatever shared or unshared folder + a lock indicator to the side, much like the native desktop representation would apply. 

Meanwhile, our confidential keeps the minus as the primary icon. 

End Design - CDM Iconography Updates (Phase 1 + 2)

From our explorations, we arrived at the following principles for our end solutions: 

1.  Prioritize for platform consistency and across-platform understandability.

2.  When push comes to shove, we should prioritize clarifying personalized access over sharing level.

3.  Iconography shouldn’t be used as the primary way to communicate permission information. It should passively reflect the current state.

4.  Iconography can be used to imply differences in folder functionality as well as in folder use cases  (centralized team repository vs one-off sharing).

The initial proposal we arrived at was a 2 part phased strategy, where: 

• In Phase 1 

  • We keep the member folder as purple and introduce only the lock design for read-only folders and the minus design for confidential folders.

• In Phase 2

  • We follow the conventions of Phase 1, but use purple to indicate team shared content and blue to note member folder content. 

  • The rationale here is that we could use this color differentiation to further market our new Dropbox for Business experience's features -- where the blue folders match the functionality of Dropbox Personal and other non-Business skus.    

One of the biggest engineering challenges we found for this initiative was how accurately our engineers could roll out these changes -- where the process of updating the icons across the surfaces,  known as "folder tagging", wasn't a 100% guarantee of coverage. To mitigate confusion and usability concerns from inaccuracy we decided to hold off on the second phase 

To design these new icon updates, I worked closely with our design systems team, platform engineers across web, desktop, and mobile environments.

To make these icons, I would use virtual machines and native OS icon files as a reference and make design decisions for platform consistency. 

The process of creating the icons was one where I would create for whole icon sets in photoshop or sketch for each size, viewport, and platform, and then converting those into icon files with programs like iconSlate or icoFX. 

The QA process was one where I would assess each icon at different scales in product or virtual machine, while our engineers would also test coverage in their environments.

Results

CDM / Dropbox for Business 3.0 released to all new small business teams and existing Beta teams in March. 

So far:

• We haven't observed additional confusion or quality issues from our customer experience / support team

• We've seeing more activation from our teams and content being added to the team space 

Additionally, these efforts have  driven future product direction by:

• Showing that we should move more towards notifications and other prominent surface areas over email as users aren't as engaged with that surface.

• Uncovering the concept of relevance/visibility at the security/permission perspective, also ensuring that the majority of content users are interacting with is relevant to them and their workflows

  • This has resulted in ongoing efforts for optimizing workflows for rollouts to large enterprise teams in CDM  

What's Next?

As we get more informed on data and behaviors of teams in this new Dropbox for Business environment, the goal will be further refinements to the user experience through incremental investments. As we see more diversity in teams and larger teams join this platform, the focus will also be closer on how to better migrate  content, onboard team members, and optimize for use cases that we might not have previously observed.