When a small company rapidly grows, it can lose its sense of family and community that made it special. We developed Looking For Lunch to have co-workers, from different parts of an organization, get to know each other, in order to make a big company feel more familiar.
It used to be that everyone who worked at Blizzard Entertainment knew each other by first and last name. Going to the cafe was like eating with a group of friends, despite working in different departments. Cultural events were shaped within this close knit community, like champaign battles and box signings when games were released, complementing the groups familiarity with each other.
But now Blizzard employees are constantly facing office changes, department re-organizations, team splits and more to accommodate the rapidly growing organization around them. While this is great for the companies future, it has taken a drastic toll on the working environment, turning familiarity to isolation. People have started to stay within their teams, minimizing cross-team collaboration and the cultural acceptance that made people excited to come to work everyday.
The first step in rebuilding a close knit community is for employees to get to know each other in a structured environment. Inspired by discipline-centered lunches, our team created a platform for cross-department employees to enjoy lunch together.
Employees can sign up for a lunch on the application. They only need to choose the day and set a range of availability. The application recognizes the employee and pairs them with three other employees from across the organization. When all groups are formed, a calendar invite is sent, providing relevant and introductory information.
Being an internal Blizzard project, our focus was solely on Blizzard employees as our target users. But there was a lot to compete with. For one thing, three discipline lunch groups already existed (i.e. project managers, artists, and engineers), to share content knowledge once a month. The other problem is that the organization, as a whole, encouraged employees to know their games and test their betas, which had many employees playing games at their desks at lunch.
Despite these obstacles, we believe we could have every person on the Blizzard campus participate in at least one lunch a week.
Research; Getting to Know the User
We conducted interviews with three key resources who ran the Blizzard discipline lunches. I also conducted rapid and random lunch time interviews to better understand employees' perspectives.
We found two major insights:
- While employees enjoy the discipline lunches, most felt that it does not provide any knowledge transfer.
- Most employees wanted to eat with other people but ended up eating alone or at their desks to play video games.
After collecting qualitative data on Blizzard employees the team had a brainstorming session to put together three personas. We decided to focus on Nibbler, as the main persona and target audience.
Throughout the process Nibbler was utilized as a resource to get the team out of our own heads and into an empathetic perspective.
Participatory Design Workshop
I wanted to create buy-in within the department and see what they had in mind when they gave us the project, so I held a participatory design workshop with many of the disciplines from our department. I facilitated the group through discovery, ideation, concept, and rationale phases.
This not only provided a number of very impactful ideas, but gave the team insights about our users, that we, as interns, could not have understood without having worked at Blizzard longer.
Ideating and Iterating
After reviewing the insights found from the interviews and participatory design session, we had more than enough information to start ideating.
In a brainstorming session, the team individually wrote down all of the ideas we could come up with on post it notes. We then presented our own ideas and continued to come up with new ideas based on those presented.
Using affinity diagramming we organizes the ideas into groups and identified the ones that we believed needed to be accomplished for the Minimum Viable Product (MVP).
Defining the Ideal
Something we learned early on in the process is that we can't have it all. A full development lifecycle for a young team takes significant time, for many reasons.
Never the less, we did not just want to design for the MVP, as it does not look at design holistically. So we organized the ideas and sorted out what the concept might look like fully developed. What it would and would not do and why, which helped shape our project's core.
Organize, Prioritize and Narrow
In the agile development process, everything revolves around prioritization. Agile only works when everything is organized into a prioritization list, so everyone knows what they are doing and is on the same page.
The team was able to prioritize the list for the MVP and create a backlog if we finished. This was the most trying aspect of the entire project because different disciplines weigh heavily on certain features or functionality. Although, once we had completed the initial list, it became easier for everyone to see what needed to be completed next.
Wireframing and Usability Testing
Once the prioritized ideas had been sketched and reviewed by the team, I proceeded to building wireframes in Axure. Wireframing allowed me to thoroughly explore user input in the space.
I laid out each page and found different ways to organize the information. Each set of iterations were usability tested, updated, iterated and tested again until we decided on a final version.
Once the pages had been validated by management, I began to test page interactions using Axure's interactive prototyping capabilities.
Hand Offs and Transitions
One of the biggest obstacles the team faced throughout the internship was creating a project language that would allow us to make clean hand offs between one another as well as support each other with proper documentation and discipline help.
Several things had to change to make this possible. By updating the way we held stand-ups, everyone felt more comfortable noting things that they did not understand or were not 100% on board for. I started annotating my wireframes with a high degree of explanation and all documents passed from me were accompanied by a brief, at desk, meeting. We also started saying out loud and emailing when something was completed and being sent out, so everyone knew each other's status.
Near the end of the internship I realized many of the ideas and next steps would be lost without some type of knowledge transfer. I created a functional Axure prototype to show what the future of the application could include if we had continued to develop it.
Future design and implementation could include:
- A mobile version of the application
- Lunches organized by topics, which people could join in a game-like lobby
- An administrator aspect to manage the current and future discipline lunches
- An expansion to make the application a one-stop-shop for all group lunches at Blizzard
- A system of accountability to decrease lunch no shows
You can never lose your design optimism. This project was not as smooth as I wanted it to be, but with guidance and perseverance, our MVP got off the ground.
Team dynamics can make or break a project and there is a much higher level of communication needed, both verbally and visually, between disciplines to keep everyone on the same page. It takes the involvement and buy-in of the entire team to be successful.
As professionals, we need to embrace our time and business constraints to be successful.
Intern Scrum Team
Leanna Verderese producer
Sean Wang co-designer
Trinity Xia developer
2015 Intern for Blizzard
Worked on in-house solutions
This project lasted 2 months
Process book compiled by Sean Wang
Final interface used in banner created by Sean Wang