Reflections — Internship at Bloomberg

I spent the summer of 2016 at Bloomberg, New York as a UX Design Intern. I recorded a reflection every day for 10 out of the 12 weeks of the internship. This post is a log of those reflections. Through this post, my only intention is to take the readers through my internship journey and by no means do I pose this as the only internship experience one can have whether at Bloomberg or elsewhere. Also this post does not include any designs and/or wireframes of the final submission due to confidentiality clauses. Before we jump into reading the reflections I want to give a big thanks to my mentors Steph, Shahtab and my partner in crime Bobby (UX Research Intern).

Also, I understand that all the reflections together add up to a pretty long read. For readers that do not have enough time to go through each day’s reflection, here is a brief summary of what it was like to intern with the amazing UX team at Bloomberg:

My internship began with getting a taste of New York City traffic. I reached 20 minutes late but to my surprise I was welcomed enthusiastically by my awesome mentors Steph and Shahtab. Soon after that I met Bobby, the UX Research Intern and soon to be good friend! On day 1 itself we were given a one-liner brief — Design a Communication and Collaboration Center for Bloomberg.

From day 2 Bobby and I began work on literature reviews and competitive analysis. The competitive analysis helped surface commonalities as well as distinct feature sets within existing tools. I began to question fundamental reasons for the need of a formal (email) versus informal (instant messaging) form of communication. Before we knew it, it was time to make our first presentation, kind of an update of work in progress. I wish I could say that we delivered a stunning presentation and that we were declared the best design interns they had ever hired. However, that wasn’t the case but we did get amazing feedback on our work and Bobby and I were able to involve designers and stakeholders into a super helpful conversation. It was time to get back to our whiteboards and affinity map the hell out of it! I love building affinity maps! The other thing we did was to work on a 4 point metric of business needs, personal expectations from internship, constraints of the timeline and limitations to evaluate our design. This technique helped us create a realistic scope for the project.

Throughout our research and design we were looking for more natural ways of doing something. For instance, how can we make the act of showing your ‘online status’ in a more natural way or what are the other ways of showing acknowledgement and appreciation other than a mere thumbs up? We had these and a ton of other unanswered questions. Talking about questions we made a list of questions for our interview participants. Preparing questions took a lot more time than I thought it would. This stage of the project highlighted the fact that the art of questioning needs to be mastered and the quality of the answer really depends on the quality of the question. We kept refining our interview style and questions with every other interview. It was truly an iterative process. Interviews consisted of collocated as well as remote ones with Bloomberg employees in other American cities, UK, etc. There was a stark difference in colocated and remote interviews with the latter being more susceptible to technology failure. This highlighted the fact that remote communication and collaboration was very much reliant on technology. Once we had all the data from our interviews, literature review and competitive analysis, we began to pull out findings and insights. Six weeks had passed by and it was time for our mid-way (second) presentation.

If there was one design method that i could choose and say I really learnt how to do this well, it would be creating Use Cases. This was tough but a lot of fun once I got the hang of it. I believe Use Cases are so important to give the design a proper direction! We also did multiple 10-minute sketch sessions and also used the round robin sketching technique. I love this stage in the design process! After several rounds of low-fidelity sketching I did some high-fidelity sketches and built prototypes out of it. After testing these prototypes we made some iterations to the design based on user feedback and then quickly moved on to creating digital wireframes.

The only thing left now was putting all the pieces together for a presentation. Never in my life had I made a 108 page slide deck for a presentation. The process of building the presentation is a whole new story on its own. Bobby and I presented for a total of 40 minutes and were able to peak interest in our stakeholders, which was evident in the 20-minutes Q&A session. To conclude, my summer at Bloomberg was amazing and I believe it was one of the best opportunities that lead to my development as a UX Designer & Researcher.

Day 1 — Finding my way

To reach 20 minutes late for your first day as an intern is not an ideal start. But you know you are at the right place with the right people when you are greeted with a smile because the other person understands you learnt the real meaning of “New York City traffic” the hard way.

My misjudgment of traffic and travel time was not frowned upon rather I was given an opportunity to acknowledge my mistake, learn from it and move forward. Amidst all the paperwork, miscellaneous formalities, setting up my desk and meeting the team, I realized that the “GO” attitude is truly a part of Bloomberg’s culture.

Looking ahead, as a User Experience Design Intern I am super excited to learn from mentors (Shahtab, Steph and the entire UX design team), collaborate with Bobby (User Experience Research Intern) and come up with a design strategy to execute and deliver designs for a communication/collaboration tool deployed in a workplace.

Can’t wait to begin Day 2!

Day 2 — What’s the plan?

The day started with making minor adjustments to the “12-week plan of action” provided to Bobby and I by our mentors Shahtab and Steph. However, like every new project the primary concern was where do we start from? Do we need to find the solution to a specific problem or do we have the liberty to look for a unique problem space through our research and insights? We must get the right design before we begin to design right.

I put together 5 key questions that would help form a clear predisposition(s). Also I believe these questions by themselves and/or when operating in conjunction with each other will inform the exercise on competitive analysis of existing collaboration and communication tools in the market.

In my opinion Bobby’s expertise and unique approach to research coupled with my human-centered design thinking will yield valuable insights and help shape a unique design proposal/solution.

Today’s conversation was very important for Bobby and I as it helped us acknowledge each other’s unique perspective and how we can leverage on it to create good design. While I work towards preparing a rough draft of competitive analysis to present on coming Friday, I am eager to see what Bobby finds through his exercise on literature review.

Day 3 & 4 — Competitive Analysis

The task of selecting and then studying a host of digital communication and collaboration tools turned out to be extremely time consuming. But through this data collection common features and trends began to appear. This also brought to light unique features offered by various tools/apps. I began to ask questions. Findings from the competitive analysis made me curious as to why one would need a certain feature or why does only one out of ten apps offer a specific feature? How does this relate to needs of people in regards to who, why, when, where and how they are communicating or collaborating. Why do we even categorize these tools as communication or collaboration tools, why can’t we have a tool that is efficient in collaboration and encourages effective communication? Trello for example is a good collaboration tool but communication between members takes the form of comments. I began to think, what if Trello adopted the communication format like that of messaging apps?

With all the communication tools being covered I am currently collecting data on feature sets of collaboration tools. I am beginning to see common patterns and contradictions. With day 4 coming to an end, I now look forward to sharing my research with Steph, Shahtab and Bobby tomorrow.

Day 5 — Email or Instant Messaging?

We are approaching a long weekend (Memorial Day on Monday) hence the day was a little more relaxed compared to the earlier ones. In terms of getting work done I continued working on the competitive analysis. Overlaps between collaboration and communication tools were starting to become more obvious. However, it wasn’t the competitive analysis that was the highlight of the day. Late afternoon I received an email from one of my mentors. He had come across a tool (Missive) that combined email and instant messaging into one single interface. Bobby had been reading about the use of email and hence it was very natural for the three of us to get into an hour long conversations of the good and the not so good bits of Missive. Without critiquing it in detail (as it does not fall under the scope of this project) I can say that the conversation led many “big questions”.

Why do we prefer using email or instant messaging? Is one more symbolic to the written word and the other being a digital replica of the spoken word? Would I use the same instant messaging app for personal (family and friends) as well as professional (colleagues and clients) context?

It is always a good sign when the team begins to explore a problem space from various perspectives and that’s exactly what this evening conversation was all about — asking questions and exploring possibilities.

Day 6 — High level view

This was a day of ups and downs. I was feeling pretty good about the Competitive Analysis chart I was working on for tomorrow’s presentation. It was only at the 2pm meeting that I realized I was not able to communicate what my research was about through this chart and that there were some gaps between the research Bobby and I had done. I stepped out of the meeting, a little frustrated and quite a few questions in my mind. In need of break, I decided to go up to the cafeteria on the 29th floor. The view from up there made people and cars look minuscule. As I watched them move a few feet with change in traffic lights, I began to wonder how in preparation of tomorrow’s presentation, I had failed to look at the big picture — the high level view. I was approaching the presentation with methods learnt at school but things in the real world differ from how they are at school. I guess I got a wake up call at the right time!

However, I wouldn’t change this day even if I could because I learnt something very important. The honesty with which Steph critiqued my work and the patience and persistence with which Shahtab expressed his thoughts and opinion told me a lot about the maturity of people I was being mentored by. I love the space I am in and the people I am working with make it special. As far as the presentation goes, things are under control and with a few changes and additions the presentation should be good to go!

Day 7 — Human-centered design

A little more than a week as interns, Bobby and I were ready deliver our first ever presentation at Bloomberg. I wish I could say it was the best presentation ever and that everyone was super impressed with all the work we had done and that we were on the right track with no modifications needed to our plan of action. However, as we all know there is no such thing as “perfect design”, or the “perfect presentation” for that matter. There is always scope for improvement.

I believe we presented well as a team with coherent transitions to each other. We took feedback and critique with open mind, provided legit rationale for our research and design plans and acknowledged our shortcomings. My key takeaways and issues to consider and/or improve on were:

• Approach — Research and design must be human centered in comparison to being heavily tech oriented. What are the fundamental human needs when people work together?
• Constraints — We must not limit our research predominantly to Slack. A comparison with other tools (Trello to a host of Google Apps or Microsoft Office 365) is important to understand the needs, tasks and context in which users communicate and collaborate.
• The context — Study into how collaboration tools are used at a start-up that is open to using any tool available in comparison to large corporations (like Bloomberg) that have higher security and thus build their own communication and collaboration systems.
• Get “Bloomberg” specific — Identify needs and common patterns of operation among Bloomberg users and analyze if these are met with internal or external tools?

For day eight I plan to continue mapping out feature sets of external tools. Day nine (last work day of the week) I would look into tools used at Bloomberg. This analysis would help later on in the project when I begin to chart out tools and/or their feature sets based on needs of Bloomberg users.

Day 8 — External tools

Today I stripped down my list of external tools from twenty four to eight. These eight tools being:

• Slack — Essentially a communication tool (instant messenger) that is touted to be closest to collaboration tools, at least in regards to team management.
• Skype — Communication app that specializes in video conferencing.
• WhatsApp — One of the instant messaging app widely used in southern Asia.
• WeChat — Most popular instant messaging app in China.
• Messenger — One of the most frequently used communication tools in the west.
• Trello — An online collaboration tool that lets you manage teams, projects, specific tasks in form of deadlines, keeping a check on employee contributions (analytics), etc.
• Yammer — It is often compared to Facebook, the only modification being that it caters to businesses and not individuals for personal (mostly leisurely) interests.
• Gmail — Popular email system.
• Blogs (in general) — A communication platform for individuals and groups of people (known or strangers to each other).

The focus for the day was to go through their feature sets and map out a much narrower/specific chart to see which tool does what. Due to confidentiality reasons I cannot share that chart here.

Day 9 — The need to build your own tools

Today I started going through the internal communication tools used at Bloomberg. Customized email, instant messaging, calendars, contacts… the list goes on. It dawned upon me, how the need to secure and protect important data has led larger corporations to built their own synchronous as well as asynchronous tools. Unfortunately I cannot (publish and hence) go into much detail with today’s study but with data from analysis of the internal as well as external tools, next week I will look for commonalities, contradictions and connections between these tools. I will take my research further by understanding the needs these tools (and their feature sets) fulfill. I am super excited about next week because I see myself spending a lot of time with sticky notes and whiteboards!!

Day 10 — Do and redo

“Design is not the final product, it’s the process.” This is one of those statements that I as a designer get reminded of on a daily basis. When I say “I get reminded of it”, I don’t mean someone walks up to me and gives me a reminder, rather it’s a conversation I find myself in every time I stare at a whiteboard covered in sticky notes and scribbles.

It takes not one or two or three but multiple rounds of analysis and data collection to understand existing models of design. These models then overplayed on top of each other paint a picture that highlights differences and similarities. Its these connections and insights that help structure further research and design methods (interviews, observatory research, participatory design, etc.) that formulate a design direction.

With the two layers of analysis (internal and external tools), tomorrow the project goes to the next level as we overlay the third layer of research findings from the literature review. This is one of the most exciting phases in any project as it forms the basis of the final proposal, be it a topic for a research paper or the final design itself.

Day 11 — Who is our primary user group?

Today the team spent more than usual time bringing together research from the literature review and the competitive analysis. An extra hour spent on understanding how both these researches tie in together proved to be very beneficial. The fuzzy next steps did not seem as fuzzy after this exercise.

We collectively decided to focus on a key question — who is the target user group? We were always aware that we had to start broad but ultimately narrow down onto a smaller group of users (a specific department within Bloomberg). But how do we go about implementing this crucial constraint that is bound to have a big influence on the design direction? How does one go about selecting one department in such a large organization? To achieve this we looked into what we wanted to achieve within the time we had.

The values and needs of the business (users) being of utmost importance, that became one of the factors to constrain our design. Secondly, what do I wish to get out of this internship? The final design must encompass a host of design methods and techniques I envision in a portfolio piece and also and exhibit critical design thinking and communication skill. This became the second unit of measurement. The third was the time limitation with less than 10 weeks at hand. Our mentors suggested we use this three-point metric system (business needs, personal expectations from internship and constraints of the timeline) to help us make a realistic decision while not restricting our design and design methods to a mere tool building exercise. We are currently working on the three-point metric system which should be completed by tomorrow afternoon.

Day 12 & 13 — A design journey is full of agreements and disagreements

Today is our third day with the three point metric system. In fact it has now turned into a 4 point metric system with “Evaluation” being the fourth metric.

Today was one of those days where we (Bobby, the research intern and I) could see differences in our approach to answering questions in regards to why we would want to undertake a particular study. It can be a challenge to get a researcher to think like a designer and vice versa. I would like to emphasis on the word “challenge” because there is nothing negative about it. Rather I believe it is this different thought process that helps cover aspects which can otherwise be easily left out (ignored) if the study is conducted only from one perspective.

In school, one can take his/her teammates for granted but in the real world one makes as much effort as he/she can to get on the same page as the other, to understand the other person’s point of view and not be committed to his/her own idea/thinking/comfort zone. Days like these make me realize that I have a lot to learn about design, teamwork, communication, standing for what I believe in and also establish the confidence in my team that I am a patient listener and a critical thinker. I don’t mind the days that start with a disagreement because the usually end with the realization of one’s own as well as the other person’s potential and strength. I consider myself fortunate to be working with a team that thinks likewise and I give complete credit to my mentors, my fellow-intern and the culture at Bloomberg for making me a more mature designer.

Day 14 — Setting your status

While talking about features to be evaluated using the four-point metric system mentioned in earlier posts, we got intrigued by the use of “status” in synchronous communication (mostly instant messaging apps). Have you ever wondered why almost all applications offer the same set of status options (such as online, offline, busy, away, etc.) Why is this the standard? How did this become the standard? In the context of instant messaging the purpose of a “status” is presence driven. Why isn’t our status reflective of how we feel rather than merely showcasing our availability. I do see some merit in the status as a “this is how I am feeling” meter when used in a personal setting (i.e. chatting with friends and family) but would this feature be beneficial when adapted into a professional setting?

Here is why I propose to add “feeling” to a status? Imagine two coworkers John and Paul, sitting side by side in an office. John is having an extremely busy day. He is swamped with work and literally on the verge of frustration. Paul can not only see how busy John is but also how annoyed and flustered he is. He can see how John feels about the situation he is in. I believe with a better understanding of what John is going through, Paul is less likely to disturb him. In fact Paul might offer to help John or even approach him at the end of day to show support which would in return result in team bonding. So why can’t we replicate this natural and unintentional communication (of knowing how one feels) when it comes to the digital world of instant messaging?

Well as of now, this is just one of the many questions that I am looking into. Throughout this internship I intend to find answers to some of these questions. But most importantly I hope to keep asking more and more questions that make myself and others wonder why certain things are the way they are and what if they existed to fulfill a very different purpose.

Day 15 — Recognition and acknowledgement

The term “human-centered design” is very crucial to my practice. It feels good when I am commended by my peers, mentors and clients for creating a design that exhibits a “human centered design approach”. Such compliments and kind words can either boost one’s ego or inspire him/her to work harder. I would like to think it is the latter for me.

However, we don’t see such patterns of recognition and acknowledgement in the digital world. At the most, these are limited to use of thumbs up and thumbs down icons. Wouldn’t it be nice to encourage your teammates or get recognized for your contribution on a project while communicating and collaborating in a digital space (instant messaging, email, video conferencing, collaborative document creation, etc.)? Why hasn’t anyone looked into translating this natural behavior to technology oriented communication and collaboration methods? What’s stopping us from doing this? Is it the nature of being in a professional setting that limits our behavior to specific actions and not give detailed and/or genuine feedback of how we feel? How can this feeling be expressed using existing channels (text, audio and video) of communication? Wouldn’t adaptation of such behavior (acknowledge good work) to digital space help teams bond and grow?

As you see, today’s day was really all about asking questions! Let’s see what answers we can find throughout this summer internship.

Day 16 — A game of question

It is Day 16. Bobby and I had a couple of tasks to finish by end of day:

• With our list strictly restricted to New York and London employees, we had to look for possible interview participants responsible for different roles in different departments at Bloomberg.
• Start to narrow down on specific areas (tasks, tools use and behavior) pertaining to a collaborative environment, which would inform the internal interview (conducted with Bloomberg employees).

Preparing a list of possible interviewees (with guidance from mentors about information on employee availability) was not a very time consuming exercise. We spent most of our day debating, questioning and analyzing reasons why we as a team want to solve a specific problem. What is the problem and if there is one, does it need to be solved. It was very important for us to understand that we were not trying to fix something that wasn’t broken in the first place. Let’s take the example of availability (status i.e. online, offline, away, etc.) in instant messaging apps. But the question I ask is what the difference between availability and approachability is? Is one approachable when available? Many would term this as word play but I believe that it is somewhere within the difference between availability and approachability that one can find a more natural way of sharing presence and also being more conscious of each other’s “situation” or “position” in the digital world before we approach them. In a professional setting, how many times have you found yourself in a place where you ask your colleague if he/she has a minute to spare and then you ask them for help (or simply ask the question you are looking an answer for)? So why in the digital world do we just barge into the other person’s space (their screen) using instant messaging apps? I am sure a lot of study has gone into digital spaces and how these can be more intuitive and natural like the physical space we live in (this covers our behavior in that space/environment as well). But this is a vast topic and one that is constantly changing as our cultural norms, behaviors, needs, and expectations change with time.

Such days remind me that design is not always about finding the solution but it is about asking questions and exploring possibilities. Design truly is a game of questions.

Day 17 — Good design takes time

There are stark differences in the way one would go about designing for a school project in comparison to working on one out in the real (professional) world. By no means do I intend to say that projects done in school are distant from reality but they do offer a wider scope to experiment, fail and learn. I feel proud to be interning with Bloomberg, an organization that does not discourage its employees to take risk, well, at least calculated risks (after all someone is running a business). As part of every user experience design project a team goes through several phases such as narrowing down on a problem space, listing down predispositions, conducting primary and secondary research, gathering insights, generating initial concepts, wireframing, visual designing, creating iterations based on feedback till the time one reaches the desired outcome. This post revolves around the interview phase (primary research) and how different my experience has been in regards to time spent on solely preparing questions for an interview for a school project in comparison to one during my internship.

In school we (the team and I) would dedicate merely a day to prepare interview questions. We would create affinity diagrams with low-level (who, what, how, where, and when) as well as high-level (why) questions. These questions would be primarily based on our predispositions and data from secondary research (example: scholarly articles). In the industry (internship), the process is very similar to the one followed in school, however it is more rigorous. The data from secondary research is extensively refined yielding not only a broader perspective towards the issue/problem at hand (why is it a problem in the first place) but also offers a better understanding of different ways the issue/problem can be approached (ways in which we can solve the problem). The emphasis here is being exposed to multiple possibilities, which means being exposed to multiple questions. To cut the long story short, here at the internship we (Bobby and I along with our mentors) are in the fourth day of structuring questions for the interview. The script for the interview has been filtered to the level where we (ux intern team) understand the reasons for the order of questions, how one question can flow into the other, how much flexibility the semi-structured nature of an interview can offer, what are the key insights that we are looking for, how much time should be dedicated to each question or section of questions and what do we expect to learn from this interview while not crossing the boundary of probing to the extent of influencing the interviewees thought process/mental model.

I have never had interview so well structured and I am looking forward to a possible (1 hour) mock interview session to be conducted tomorrow. Going back to my point on stark differences between school and real-world industry projects, I can surely say that the level of detail and specificity is immaculate in the latter and one of the reasons for this is the time spent on digging deep into the issue. When you get to have design discussions and see your research and design plan get more polished/refined as it goes through multiple passes (feedbacks/suggestions/critiques), you are at the right place doing the right thing with the right people. And that there is a lot to learn!

Example question: 1) “How do you determine if a teammate is available to talk?” vs “If you want to get a hold of someone, how do you go about doing it?” 2) “What kind of notifications do you get while collaborating with others?” vs “Tell us about a time when you experienced disturbance in a workflow.”

Day 18 — Flow of an Interview

Designers conduct interviews for multiple purposes that yield different results and explore varied insights. Some of them could be:

• Who does what, why, when, where and how?
• Validating your thought process about who does what, why, when, where and how.
• Why does something (product and/or behavior) work the way it does or why does it not work in a particular way?
• Find patterns (of product use, user behavior, general trends, etc.)

An ideal interview would look into all of the above mentioned points but we know there is no such thing as an ideal interview (or design), at least not for us designers. We constantly question not only current technologies but even the foundations that these technologies are based on such as user needs which keep changing with time and modifications in culture and beliefs. With this in the back of our mind, how does one go about framing an interview script? It’s a challenge!

Day 19 & 20 — Iterative process

With completion of two (excluding mock interview done on 16th June) internal interviews, one on the 17th June and the other today, I can clearly state that it is not only producing design that is an iterative process but research and interviews also mature and refine with every other interview.

We decided that Bobby being the research intern should take lead in asking questions while I take notes for the duration of entire interview along with asking occasional and specific questions not being probed by Bobby. An interviewer has a lot on mind and hence a note-taker must be very vigilant throughout the interview process to make sure nothing gets missed out. As a team, I believe we did a good job which was also reflected in comments from our mentors. However, based on the first interview we modified the script for the second one. Changes were made based on mentor feedback and suggestions as well.

Some of the changes we made:

• Terminology of some questions that startled or put off the interviewees.
• Sitting arrangement to facilitate better communication between Bobby and I. This helped in better flow (whenever I had to jump in and ask a question or even communicate time to Bobby)
• Change some questions to get more detailed and specific answers from interviewees/participants.
• We decided to give more prominence to certain section and cut down on time on some others.
• We introduced a sticky note exercise in which the interviewee creates a list of items and then puts them in categories. This helped us in getting clear data that we believe will yield quality insights.

After today’s interview we (Bobby and I) have decided not to change the script or format for the two or three interviews to be conducted tomorrow. However, I believe tomorrow’s interviews will be an iteration of the ones conducted earlier, yielding better insights for exploring possible design directions.

Day 21 — Similarities and differences

So far we have data from 4 interviews. This data comes from users who are also stakeholders. Below is their compiled (brief) demographic info:

• Age: 25–55
• Years with Bloomberg: 1–28
• Specialization: User Experience, Engineering and Product Management

In spite of having interviewees come from diverse backgrounds, experience and age groups, similarities in tool use (purpose and frequency of use) were starting to become apparent. On the other hand we could spot differences in regards to social aspects and perceptions related to availability, distractions at work, recognition of work and need for collaboration.

With more interviews to follow throughout the week, we hope to come across more commonalities and contradictions among interview participants. By end of week, we should have a better understanding of user’s breakthroughs and breakdowns, which would then be analyzed and questioned to get insights.

Day 22 — Note-taking and revisiting interviews

So far this week has been about either conducting interviews or analyzing data from the interviews. It can be a challenge to make note of all that is expressed by interviewee. As we all know, it’s not only about what is said but also how it is said (or done). People might not always practice what they say, not due to any ill intention but purely because that’s what they believe in at that particular moment. So how does one go about capturing true data? Also how does a designer interpret a piece of information at that specific time when the interview is being conducted in comparison to listening to a recording later? I do not have a perfect answer to this question and but I do have some thoughts on it.

In my opinion both methods help discover very different insights due to the spontaneity of one method and the luxury to freeze and/or go back in time with the other. During an interview, the participant is asked questions that make him/her think hard on issues, that otherwise might be second nature. It can be difficult for the participant to completely be himself/herself which makes it tricky for the interviewer to get true data. However, it is the acceptance of this volatility that helps a good interviewer record/decipher insights. But being in the moment, trying to record the spoken or written word along with the pauses can be overwhelming. This is where recording the audio comes in handy. Audio recording help not only in finding new data (that you missed originally) but also to validate notes taken during the interview.

To rely solely on written (and sketched) notes or just a recording is surely not the best way to go about capturing and then analyzing an interview. The practice of being able to record and assess data in real-time and also evaluate it with the help of audio recordings is key to finding better insights.

Day 23 — Remote and collocated

Today we had 3 interviews, two of which were in person with stakeholders/users at the New York (Lexington) office and the third one a video conference call with Bloomberg staff in London. In the past with all our collocated interviews Bobby and I had our set roles with him largely questioning and engaging in conversation with the participants while I took notes on the participant’s response. With most of the interviews I would either take 5–10 minutes at the end to ask questions (that I had been noting down throughout the interview) or simply raise my hand during the interview when I wanted a question answered (keeping in mind that I did so only during transition points from one topic/section to the other).

With the participant being remotely located, Bobby and I were faced with the question whether we should retain the same format of me asking questions in between topics or at the end or try something different. We believed it would be less distracting for the participant to converse with only one of us. As a result, instead of interrupting in between topics, we decided that I would instant message Bobby with a list of questions throughout the interview and he could ask them in the interest of restricting the communication just between the two of them. But halfway into the interview we realized that doing so was not a very clever move. This was a classic case of “…if it’s not broken, don’t try to fix it.” My instant messages (questions) to Bobby started to become more of a distraction than assistance. This method of communication interrupted his flow of thought. The interview made it apparent that one’s perception could change based on the fact whether communication/collaboration is to take place remotely or in a collocated space. It also made it clear that as researchers and designers we have to be flexible and adaptive enough to modify the plan of action/execution or in some cases simply acknowledge that the new method isn’t working and one must revert back to the older format.

For me today’s interviews (especially the remote interview) brought to light how a slight change, if not well thought, can disturb the flow and process of any exercise. But such experiments always leave one with some valuable insights.

Day 24 — Looking back at the interviews

One of the key differences for me between being in the moment, listening to the interviewee in comparison to listening to the interview recording at a later time was the difference between “Oh… that’s something interesting” to “I wonder why he/she said that”. Recordings (audio or written) can lead to a deeper inspection into the topic in comparison to being hit by a thought during the time of the interview. Depending on the time at hand one can either have the luxury of going back to the participant for a second round of interview or try using that question coupled with one’s predispositions and other research to find valuable insights.

So today was all about going through 9 hours of audio recording, trying to categorize and rewrite notes (data and insights) individually which would then be validated with the team’s notes. Apart from validation, this exercise will help us make sure that not much data and insights are ignored.

Day 25 — Two minds are better than one

After carefully going through notes and recordings and then refining/rewriting the notes of all nine interviews, it was time for Bobby and I to compare our notes. This is the phase before we sit together to analyze and make clusters of commonalities and also question or in some cases bridge the gap between contradictory statements made by our panel of stakeholders/users/interviewees. It is amazing how this exercise makes it crystal clear that if only one of us was to conduct the interview and take notes, there would be a big void in our data collection. There were some very detailed observations that I had missed out on but Bobby had a good recollection of them. I had made a note of quite a few behavioral aspects and user needs that slipped through Bobby’s notes. Both of our recordings combined, consisted of several repetitive notes that assured we were on the right track.

Moral of the day: Two minds are better than one.

We then presented our findings to Shahtab and Steph (our mentors). The next step was to make an agenda for the week (week’s plan listed below).

Day 26, 27, 28 and 29 — Process of pulling out key insights

I haven’t reflected since the last 3 days and the reason for that is continuous analysis of interviews. We took all the data (from interview) that was in form of a script (text) and created a rather unusual looking affinity chart. Below is an image that describes the process of moving from the script to an all encompassing affinity chart to one that depicts key insights and takeaways to inform user needs and find critical problem spaces.

Day 30 and 31 — Midway Presentation

Preparing for the midway presentation forced us to better understand the data and also where we were at with the project. Most of last week and these two days have been pretty exhaustive and with not much time to reflect every day. The best way to reflect would be to show you the midway presentation but for confidentiality clauses I cannot. To give you a basic idea, this presentation outlined work done so far and also stated the kind of feedback we were looking for from the second presentation.

Day 32 — Recap of research phase

We dedicated the first 7 weeks of the internship solely to research. This included a literature review to study models and mechanisms of communication and collaboration, a competitive analysis of communication (instant messaging apps, email, etc.) and collaboration (project management, etc.) to get a better understanding of needs fulfilled by tools within Bloomberg to that of tools used externally (out of Bloomberg). The literature review and competitive analysis helped structure the interview script. We then conducted 10 interviews with users/stakeholders from different departments within Bloomberg. Interviews resulted in roughly 400 pieces of raw data and insight. A rigorous filtering process led to segregation of key data and insights into 25 categories. These 25 categories were then narrowed down to 5 in the form of an overview of how we saw “collaboration” at Bloomberg. Within each category we listed key findings, which further led to either a design question or a design needs.

Day 33 — Use Cases

After almost 7 weeks of research, it is now time shift gears and move on to the design phase of the project. This starts with Use Cases. There is a tried and tested formula for creating Use Cases. This is how it goes…

As a … (persona / the who)

I want to … (goal / the what)

So that I can … (value or measure of success / the why)

But how is this exercise helpful? The process of coming up with these Use Cases helped me be more critical and ask questions I would have otherwise missed. I also expect these Use Cases to inform my initial concepts / design sketches.

It’s always fun when it’s time for the pencil to meet the paper! Looks like that day is going to be this Monday (07/11/16).

Day 34 and 35 —More Use Cases

I was wrong. It wasn’t yet time to start sketching. Two back to back days building Use Cases made me realize how tedious of a job this really is. It requires absolute clarity and understanding on the designer’s end to not only create Use Cases in a time efficient manner but also, with extreme specificity in regards to the actual issue being addressed and once addressed what value would this bring to the user. Does this Use Case satisfy a design need/issue or give answers to a design question being asked?

During this exercise, I would often say something and then try to refine it so that I could make a Use Case out of it. However in most cases it was the first thought that had more clarity because the harder I tried to justify a Use Case, the more muddled its explanation became. There are many useful blogs on creating Use Cases but in my opinion these provide an essential but only the initial push towards understanding what goes into building Use Cases. This is a skill that needs time and practice to develop!

The good and not so good Use Case:

As a team member, I want to send emails to my team, so that I can send formal notices to the whole team.

Even though the above mentioned Use Case follows the correct structure (of As a … I want … So that I can …) the problem is that the “So that I can …” does not add much value. One must always question the “So that I can …” with a “So what”. ( Example: So what if I can send formal notices to the whole team?)

Now let’s change things around a little and restructure the Use Case.

As a team member, I want to send formal notices/updates to the whole team, so that all team members are aware of the importance of this announcement and that they are on the same page.

Both these Use Cases are saying the same thing but the second one adds a lot more value and give the designer a metric (are people aware of its importance and are they on the same page) to measure the success of design. And that’s what a good Use Case does, it helps you look for specific results that give validation to your claims of whether the design achieves its goal or not.

So to conclude, I would say Use Cases lead to deeper investigation of a problem space, assist in sketching ideas, concepts and possible solutions and also help in measuring the success of your design.

Day 36 and 37 — Time to sketch!

The skill of communicating through sketches is of utmost importance to a designer. This communication happens not only between a designer and his/her team members or even a client but it is also a communication that a designer has with himself/herself. Many ideas that otherwise could have slipped through the cracks get highlighted through the process of sketching.

A sketch becomes more powerful when shared with others. Without a clear explanation, low fidelity sketches open doors to different interpretations by different viewers. The time in which a sketch is created also has an effect on the sketch itself (not only in appearance/visual but as an idea/thought process).

If I had to think of three words that collectively defined this phase of the project (quick sketching/idea generation), they would be: create, explore and discover.

Day 38 and 39 — Ten-minute sketch sessions

Throughout this internship I have come across new ways of doing things. I have asked questions that I would have not asked before. I have gone about performing research and analysis with a lot more depth. I am enjoying every bit of this experience but sometimes it does get a little overwhelming. And when it does, days like today provide the needed reassurance that I am on the right track and that I am in considerable control of what is happening.

I spent two days doing ten-minute sketch sessions, alternating between the different themes of availability, search, file sharing, centralized vs decentralized functions, notifications and managing formal vs informal conversations. The time limitation forced me to commit to an idea but only for 10 minutes, after which it was fresh start all over again. Continuous feedback on sketches from others (people involved in the project or not) helps check that they are easy to understand.

I am not an artist but I love doing design sketches. They help me think!

Day 40 — Low fidelity sketches for high level ideation

Idea generation through high level sketching is always fun. One doesn’t have to pay attention to details rather it is the lack of details that helps one have multiple interpretation about the same sketch. After creating tons of sketches I narrowed down on 7 high level designs to be used for an early user feedback session. From this session I hope to get a much clearer direction, make sure the user has a need that the proposed design can cater to. Apart from getting validation from the user the low fidelity nature of the sketch helps generate conversation that might lead to new ideas and insights.

Day 41 — Interpretations, needs and design

Rough sketches were done and it was time to test these with users.

Things to keep in mind:

• What is the user’s interpretation of the sketches?
• Does the user understand these high level designs suggestions?
• Do any of the suggested designs meet user’s needs?
• Why does the user prefer a particular design suggestion over the other?
• Do we see any contradictions or common patterns (based on user’s answers)?
• Are there any particular suggestions made by the user?
• What can I infer about the user’s workflow?
• Which tool(s) is predominantly used?

Day 42 — Power of Excel sheets

Before this internship I hated using Excel sheets. But having done several rounds of data analysis, I have realized how powerful Excel sheets can be for a designer (or at least me) when it comes to getting more clarity about the data generated or communicating this data to others. It is much easier to notice common patterns and also get a better understanding of one’s workflow. I believe it is due to this clarity, that in team discussion one can realize mistakes or find more relevant ways of questioning the user and/or creating sketches. Almost all of today was spent arranging data (collected through testing low fidelity sketches with 8 users) into an Excel sheet. This followed by a 1 hour team meeting to explain the findings. Based off of these findings I will:

• Create a general overview of the tools used, functions performed, overcome current shortcomings and define needs fulfilled by the Collaboration Center.
• List down next steps in the design process (including testing)
• Decide on final deliverables

Day 43, 44, 45, 46, 47 and 48 — Sketch, test and wireframe

The last 6 days have been about sketching, testing the sketches with stakeholders, iterating on the sketches and then creating wireframes. Days have been longer than usual due to which I haven’t been able to write daily reflections. Throughout this exercise I have found gaps in the design and come across possibilities of different interpretations from stakeholders and users. This has helped me question the design at multiple levels leading to its refinement.

Day 49 — Taking a step back

• Going back to the findings and design needs.
• Check if the design caters to the design needs. Am I missing anything? Why did I choose to work on this and not on that (constraints — time, scope, etc.).
• Refining the design and wireframes.
• What’s the bigger picture
• Presentation prep

CONCLUSION

As you can see, my reflection for day 49 was extremely brief. This was end of week 10 and the 2 weeks after that went by as a blur. The last two weeks were spent refining the design and getting all the research and designs together for the final presentation. Before we (Bobby and I) knew, we were standing in front of senior Bloomberg executives and stakeholders, delivering our final presentation. We got amazing feedback and recognition.

I genuinely believe that last summer (2016) couldn’t have been any better! I returned to Bloomington not only as a more learned and polished UX Designer but also an individual who had put on an extra 25 pounds because of his love pizzas, pho, hot dogs, and chocolate.