The Challenge: Revamp employee workflows

Goals & objectives

The goal of the project was to marry the Mac Touch Bar and the Bloomberg Terminal in a way that would facilitate and maximize workflow efficiency. Our primary objectives were the following:

1. Highlight customization for worker preferences and requirements.

2. Seamlessly integrate the Bloomberg Terminal and Mac Touch Bar capabilities.

3. Provide internal employees with the tools to efficiently complete their tasks.

4. Create a refined interface and a working Touch Bar/Desktop prototype.

Acknowledging constraints and developing mitigation strategies

Working with a big corporation comes with its unique set administrative hurdles and restrictions to overcome. Our client was very transparent and accommodating, however, because there were many moving parts within the organization, we were faced with limitations.

1. Difficulty coordinating user research studies and user feedback sessions due to privacy concerns and limited scope of users.

   Mitigation: Narrowed the scope of users to software engineers and connected with as many internal Bloomberg software engineers as possible for initial interviews.

2. Ambitious project in regards to both designing and implementing a Touch Bar application within the span of 4 months with limited working knowledge in Xcode/Objective-C.

   Mitigation: Consistently communicated with the client to express concerns and compromise on a reduced project scope to deliver a minimum viable product that prioritizes a refined concept design. Brought in technical help and focused on self-guided research and learning.

3. Did not have direct access to related software like the Bloomberg Terminal or internal tools, which made the feasibility and micro-interactions harder to understand.

   Mitigation: The client was able to organize in-person meetings where he demoed the Terminal and answered any questions the team had, giving us firsthand experience with operating the tools and building mental models surrounding the product. 

Defining the approach

In an effort to carry out a project that’s productive and thoroughly documented, we placed a lot of emphasis on the organizational components of this project by outlining the respective schedule, tasks, and deliverables. We also created risk assessments each week to debrief the client on our recent progress, risks + mitigation tactics, and upcoming work. We defined our process through 5 distinct phases:

1. Project Scope/Learning: Understanding the scope and expectations of the project was paramount to its success as we needed to adequately recognize what we were designing for. This involved deliverables like a comprehensive project plan and feasibility report.

2. Design: The design phase followed traditional HCI design methodologies and techniques, consisting of user research, wireframes, iterative design feedback, and interactive mockups.

3. Implementation: The implementation was completed in sprints with a steep learning curve. The team utilized methods like peer programming and unit testing to deliver baseline functionality.

4. Quality Assurance: To test the major elements of the technical prototype, the team defined testing plans and system testing to augment the design and provide a cohesive concept for the client.

5. Final Delivery: Handing over the project and transferring IP ownership was an important stage in the process and allowed us to communicate to the client and other stakeholders what our project entailed. We were able to showcase our work and gain final feedback.

Learning: Understanding the scope

In order to fully understand how to approach the design process, it was important for our team to familiarize ourselves with Bloomberg’s current systems and their potential problem areas. Thus, we kicked off the project with in-depth planning and discovery.

Breaking down primary tasks and jobs to be done

Our team began by creating a work breakdown structure of the major milestones and tasks we anticipated. This was where we were able to visualize and speak through the different stages of the project and how we would complete them.

Crafting a cohesive project plan

The project plan is a living document that was composed of a schedule that tracked the progress and status of each phase, task, and deliverable. It also included the member(s) who were overseeing a certain aspect of the project, its respective time frame, and its dependencies. This plan was necessary for effective time management and transparency with the client.

Delivering regular updates via four-box reports

Four-box reports provided the client with weekly overviews of our progress, concerns, and expectations as a way to ensure regular updates. This facilitated conversations, drove feedback sessions, and gave the client insight into how our team was working.

Assessing feasibility

The feasibility report is an in-depth document that formalized the procedures we envisioned from the technical perspective. It involved our research behind Xcode and the key deliverables as well as business considerations and visibility plans. This allowed the team to conduct a thorough analysis of the project requirements and of what can be done in the time frame given.

The Discovery: Recognizing SWE workflows

Identifying the current workflows and routines of Bloomberg’s internal employees was essential to guiding our design efforts. Due to the qualitative nature of the information we wanted to gather, we decided to conduct user interviews because they would allow us to conversationally engage with our target audience in a way that facilitated follow-up questions and shared experiences. These interviews were conducted via Bloomberg Nexi, their video conferencing software, because their team was in NYC while ours was in Ithaca. We were able to schedule interviews with four internal software engineers.

After outlining an interview protocol and piloting the questions within the team, we carried out the plan via 30 minute interviews. One member of the team was interviewing and corresponding with the participant while another was responsible for taking notes and recording the conversation. We were able to glean insights from our questions, which prompted walkthroughs and personal anecdotes that we could then sift through afterwards. This involved questioning topics like their current work routines, what their job role requires, and how they currently interact with the Terminal.

Affinity diagramming uncovered user needs and pain points

We consolidated and organized the findings thematically via an affinity diagram where we were able to synthesize different patterns and trends. This method was particularly effective because it presented an overview of the relationships within the data, which allowed us to narrow down the most frequent or pervasive themes and highlight them across the four engineers to inform us of emerging pain points. 

Making sense of the findings: 

• Software engineers interact with the Terminal at different capacities; some only use it to check their email and read the news, while others regularly run test scripts and debug through the Terminal. They expect their work tools to align with their tasks and perform needed functions instantaneously.

• Software engineers value time, speed, and convenience. The Terminal is not software that they’re formally trained in, but rather a self-guided learning process. Thus, the workers expect its usage to be relatively intuitive and not hinder them from completing tasks.

• Software engineers have different work stations; whether they dock their Macbook or use the Bloomberg PCs and keyboard, they expect their preferred tools to translate and transfer seamlessly.

• Having to remember various commands is a grueling task and can get repetitive, especially if they’re stacked and recurring. Software engineers want commands that they constantly execute to be at their fingertips.

Sketches & preliminary explorations

Brainstorming sketches

To kickstart the idea generation and design process, we sat down as a team and underwent a 10 minute silent brainstorming session where each member sketched their ideas for potential designs. This fostered diverse ideas that were based off of our research findings, and we were then able to extract commonalities between our sketches. 

Prioritizing capabilities

We all agreed that the design needed to encompass two main parts: (1) a desktop application where users can configure their commands, reformat the Touch Bar, and tinker with relevant keys and (2) a Touch Bar where users can access their keys and use their capabilities in conjunction with the Terminal.

The features we identified would allow users to customize, manage, and organize their Touch Bar in the future, satisfying their values of saving time and working more efficiently. Giving the autonomy to users was our biggest priority, and this led to not only administrative features like editing, deleting, and adding keys, but also adaptable ones like dragging and dropping keys into their desired positions.

Iterating via medium-fidelity wireframes

We created medium-fidelity wireframes that reflected the features we discussed, but that also reflected familiarity. Usability concerns like visibility were difficult to address because we found that many of the SWEs we spoke with were not substantially versed in the Terminal nor the detailed capabilities of the Touch Bar. We didn’t want to create secondary layers like having to use the “fn” key to uncover additional features. Instead, we wanted the design to be practical and easy to use. Our wireframes were met by feedback sessions with our client since it was not possible to schedule additional calls with other SWEs.

Touch bar

Since the Touch Bar is a pretty limited form factor, we wanted to keep the displayed functions at a minimum in an effort to prevent overcrowding such a narrow space. We decided that it was important to allow employees to reorder their Touch Bar keys, access those keys, and create a custom key by prompting the desktop application. We also explored the possibility of creating a “jittering” function, a standard iOS animation that signals that users can drag and drop elements on the screen, because we thought it would be familiar and engaging.

Feedback: The edit and create key buttons are necessary functions, but can be consolidated into a set of tasks that can be completed by opening the desktop application. The Touch Bar still seemed to be too crowded with these external functions, whereas the keys should be at the forefront of the design. There’s also discrepancies between the wireframe, Bloomberg’s current design, and Apple’s capabilities. The Touch Bar does not currently support jittering keys, and there’s already a system in place that allows users to reconfigure their Touch Bar based on their current application. We needed to bring the Bloomberg keyboard into the Touch Bar and focus on how we can better integrate existing technology and design systems to fit our needs.

Desktop interface

The supplementary desktop application is a way for users to manage their workflow through a simple tab system where they can view, configure, and create keys. The most significant feature is a database of all the most common and/or useful commands where employees can familiarize themselves with keys that they can then add to their Touch Bar. We wanted to reflect what their Touch Bar would display when they reordered its keys in the app, and we wanted to capitalize on that familiarity further by mapping the design as closely to the Bloomberg keyboard as possible.

Feedback: Reconfiguring the Touch Bar is already a feature that Apple provides and reinventing that functionality would be counterintuitive if it’s already a familiar system in place. The database of keys is also a feature that Bloomberg would not be able to support because it cannot provide a list of commands to a third-party application. Instead, this would have to be entirely self-initiated or a part of a default set.

The Final Design: High-fidelity mockups

We landed on a final design after iterating and improving upon the areas in which we received feedback. The final mockups reflect Apple and Bloomberg’s existing design systems, emphasize familiarity, and give workers customization options in a concise and intuitive manner.

Simplifying the Touch Bar display even further, we opted to give the user a default set of keys, similar to the layout of the Bloomberg keyboard, which houses some of the most commonly used keys, designated by their own color family (e.g. yellow, green). The window icon is the only button that triggers the desktop interface, which is where all granular functions can be performed. We took this straightforward approach to lessen the cognitive load for employees and emphasize the effortlessness and simplicity of integrating it into their workflows.

Touch bar

This design prioritizes the keys and maximizes the allotted space. We used Bloomberg’s existing designs for their keys in regards to color and presentation, and we replicated Apple’s Touch Bar design principles through the representation and shape of the keys.

Desktop interface

The desktop interface primarily underwent a style overhaul and demonstrates Apple’s design guidelines. The tab system was broken down even further into “All Keys”, “Current Keys”, and “Custom Keys”, which allows users to save a set of keys to their own personal database, manage the keys they’re currently using in the Touch Bar, and access their custom keys. We felt this configuration was more intuitive, and it’s paired with toolbar buttons that allow users to add custom keys and configure the Touch Bar right at their fingertips. Providing search capabilities and quick edit gives users the ability to save time and manage a large amount of keys.

We decided on a grid system because colors are one of the biggest indicators for keys; each key also does not require a plethora of information aside from its abbreviation and description, which is why a grid layout imparts the most effective presentation. 

Customization is easily one of the most important qualities of the design. From the color, name, description, and command, users can create their own keys and place them at the front of their Touch Bar. By leveraging Apple’s existing Touch Bar customization tools, users can start off with a default set to familiarize themselves with common Terminal commands before discovering their own technical preferences and needs. This approach accommodates diverse working styles, tasks, and literacies, addressing our identified user needs.

Interactive prototype

A walkthrough of the concept design for the desktop interface of the application. Main features include adding a custom key, configuring the Touch Bar, and viewing a database (all, current, custom) of keys.

Implementing baseline functionality

Our developers were able to use storyboards to display a set of keys on the Touch Bar, successfully programming minimal components for a proof of concept. The final result allows users to add a custom key to the Touch Bar, trigger the desktop interface from the Touch Bar, and access basic UI components like the tab system. The custom keys print their respective commands, which would execute its function inside the Terminal.

The Results: Pitching to Bloomberg

Given the constraints and limitations of the project, we were unable to conduct formal user testing sessions. However, we conducted review sessions and usability testing as a team to assess the design principles of our final solution. We concluded the project with a formal pitch to our client, software engineers, and stakeholders by conducting a walkthrough of the entire project, demoing the final solution, and answering any questions. We received entirely positive feedback and maximum marks.

Final thoughts

Designing and coding a Mac Touch Bar application in four months was not an easy feat. We were met with countless roadblocks, but they resulted in learning opportunities, avenues for communication, and team collaboration. As my first time working with a large corporation, it was refreshing to experience a different way of approaching the design process as compared to start-ups and student-run organizations. This project was an enriching experience that allowed me to build meaningful relationships. Some of my key lessons learned are the following:

Engage in transparent and consistent communication – one of the hardest parts of this project was having a difficult conversation with our client when we felt we couldn’t deliver a robust design with its accompanying implementation. Reducing the scope made it feel like we were disappointing our client, but after justifying our ask, our client was very understanding. This experience gave me more courage to confront these challenging situations and it emphasizes the importance of transparency in the workplace.

Adhere to a thorough design process – delineating stages for our project and following a detailed account of our process was helpful in keeping the team focused and managing our time. Being able to follow the HCI design process gave us the opportunity to support our design decisions with testimonies and anecdotes of the users we were designing for.
Create a positive team culture – working effectively and efficiently relies heavily on how well the team works together. Being able to collaborate with talented and driven team members was one of the most gratifying elements of this project, and it showed me that working with like minded individuals often results in quality work.