Disney : Designing 200K Software Requests

TL;DR

Disney-- much like many large companies, was plagued with inefficiencies in its software request processes. I came in as the sole designer (with very little resources) on the team to tackle the problem of designing a scalable platform for 200K employees, that could shorten the software request timeline from 6 arduous weeks to less than 1 week.


The Challenge

Disney has a fragmented internal software request system for their 200K employees, split among many departments. Part of this is due to the nature of a large corporation, the many different needs of teams across the company (everything from studio design to accounting and engineering), and the highly specialized needs of each individual team. In return, the team that managed internal tools and permissions within Disney was inundated with requests on understanding how they could maximize the potential of their teams through different applications and platforms. This led to a slow moving process that prevented product owners from doing their real jobs, and instead spent time "working on working", or explaining the same set of tools multiple times a day to different teams.


The Current Landscape

If a team lead wanted to request new software for their team, the process usually would look like this:

In part, this slow moving process was due to the structure of processes and decentralized nature of the different branches within Disney. While this structure proved to work well for individual branches, any situations that had to do with centralized processes across different branches became increasingly difficult.

My role

I came in as the sole product designer on the DTSS team, the centralized team that dealt with all software requests in the Walt Disney company. Prior to my joining, the team had attempted various ways of centralizing this information, but had failed many times. Previous solutions all ended up being outdated wikis or mounds of documentation that nobody (especially busy teams) had time to sift through, and product owners within my team still ended up fielding dozens of requests per week for new software.

The Approach

Rather than diving directly into a solution, I started this project by understanding why the previous attempts had failed, and what could have been done better. This included setting up various meetings with stakeholders on my team, different team members in different functions across Disney, and performing a heuristic evaluation of prior attempts. I also read up on internal tools in different companies, and their approach to tackling the software request problem.

The Solution

With this project, I attempted to remedy this inefficiency through two ways: 1) software request process restructured and 2) a technology platform that could function as an internal app store.

By redefining what the software request process would be, and tying it directly into the IT portal, teams looking for new software would be able to have a clearer idea of what steps they needed to take to submit a request.

In addition, I designed a new user interface (meant to be built on top of the ServiceNow portal, an existing solution Disney had already implemented) to both educate on differences between similar software, and receive software requests. This would serve as a preliminary diagnosis tool for users seeking to better understand what tools they could potentially use, and also allow our team to field requests and set up meeting times if necessary.

I tackled this challenge primarily from the team request perspective, with room for extendability of features if necessary from our team’s side.

Looking back

What I would do differently:

Experience: As I approached this project primarily through the request side, I think it would’ve been beneficial if I also fleshed out the other side. I had chosen to do a quick-and-dirty concept mock, moving to the stage where I was working with the implementation side of Service Now when I left, but did not have adequate time (given that this was a part time internship) to fully flesh out this concept from the other side as well. In addition, due to some bureaucracy issues, I was not able to fully user test interactions out. If I were to go back, I'd definitely try to validate my design decisions at more steps of the process.

Visual: I chose to go with a very simple color scheme with high contrast, as I knew those who took on this project after I did would have to adhere to style guides within Disney. If I had the time, I would’ve also liked to explore branding for internal tools at Disney, which would’ve extended beyond just the software request portal to all touchpoints within Disney, including entering hours, etc.

Process: Although I tried my best to have 1:1 conversations with key stakeholders and different people within the team, I think this project would’ve benefited from a kickoff meeting, bringing everyone into the same team and to agree on the scope of the project. This would’ve helped align the team on what needed to be done, and perhaps pushed along the platform in a much timely manner. This was in part due to my timeline (I was balancing a full courseload at the time, and did not have as much flexibility in scheduling meeting times with the full team), and my lack of experience in getting buy-in my vision. I’ve learned that transparency and alignment on vision is ultimately key to a successful product, and going forward (given this experience), I would definitely further my soft skills in pushing a product forward.

Thoughts

I think this was an incredible experience-- to be able to dive in to a problem that would affect 200K employees across Disney, and to be able to utilize design to improve this experience of requesting software. This was definitely also incredibly challenging-- as the sole designer on the team, I did not have extra eyes to critique my designs. Looking back, there are definitely visual design touchups I could do, but I do think that the concepts of the MVP were warranted.


View Next Project


View Previous Project