From our meeting we discussed a few different types of user:
From this, we might expect our extremes to look like Quiet-Savvy, Quiet-Shy, Loud-Savvy, Loud-Shy which could be captured with the following descriptions:
For all of our users, it seems like the universal goal is to be able to talk to people who are in different locations in order to coordinate efforts, catch up on projects, or collaboratively develop some “thing.” The goals of our individual users are nuanced however:
From this we might distil the following:
There are several axes that can describe our users:
And there are axes which can describe the meetings themselves:
We discovered that for our interviewed users, they focused most on problems that occurred during the call itself, which involved technical problems, social quirks of the people in the meeting, and context for the call. In particular, we noticed that our interviewers when describing their technical experience with calls talked about several "workarounds," things they do that are not explicitly part of the conference calling application, as being typical of their interaction with their software. These workarounds, which involve using email to message people within the meeting during the meeting, using external technology to improve quality of the call, or using tools outside of the application to be productive all might spring from several motivations. The two biggest we believe are the feeling that they can't ask for help with the interface during a meeting because it detracts from the meeting, and that when the interface doesn't work the first time they have to develop a real time solution for it. Since this is an interface that they work with only on calls, there is no method of "learning" the interface outside of active meetings, which detracts from the meeting. If they don't want to ask for help., they can't learn more about the interface - the less they learn about the interface, the few functions they use - and so on.
In a first pass, we've attempted to characterize our users further and identify the goals they have for conference calling in order to inform our inspirations.
For some of our users, their main goal is to have a productive meeting in which people who may not necessarily be in the same office or department can work on something collaboratively. Director Denise, a technologically ‘shy’ user who plays a large role in establishing and running meetings, is particularly focused on making her meetings as productive as possible. It is less important to her to see everyone else, and more important that everyone hear each other. Additionally, it is critical to her to know who is on the call, what they are doing, and where they are doing ‘it’ - the productive task. Of current conference call features, Denise might like using the screenshare option within the call, and request that everyone be working from a common document, perhaps over a cloud-based sharing service or instant messenger. Thinking then about these needs, we have discussed a productivity focused conference call, in which the focus on the collaborative experience centered about a task. The meeting organizer may set-up a task, and invite people to work on the task with them at a set time or place (this is the meeting). When people join the task at a set-time, the screen shown is a collaborative document suitable to the pre-determined task with smaller “conference call” features like sub-screen camera viewing, or a list of present people that highlights on who is talking/viewing the page, etc. In this way, the design would be like a union of Google Drive or Sharepoint - two collaborative working environments - with a consumer calling service like Google Hangouts or Skype. The advantages of a productivity-focused application is that there would be history of the call recorded on a document that would be accessible to the group following the meeting. The meeting would be focused around a specific task that everyone could contribute to silently or loudly if they so desire, and the ownership of the meeting can be shared amongst the members contributing to the general document. This might solve some issues in call fidelity, because what people say and discuss will be captured in the document rather than the ether. This idea mostly supports Director Denise, but this is also a way for Coder Cathy and Intern Nelson to feel involved and active in calls via their two distinctive styles of interacting with others. For Seasoned Sam, this may not change very much how he interacts with a call, but may help him organize his physical computer screen, and on the backend of a meeting when he wishes to review later.
Frequently, after a conference call, users have to follow up with other people who were on the call. Today, that is often done over email. Additionally, IM chat is frequently used to keep track of links and documents. Some conference call services, such as Skype for Business, keep a record of the IM chat, which can often be helpful for reviewing what happened in the call. Blackboard, the education software, accomplishes a number of these things in its interface. Documents and links are easily saved by the moderator, and all of the users can see and interact with those artifacts. This feature would remove the common need to send docs and links throughout the call. Moderators can also create assignments, which can be abstracted to a to-do list. This could replace a typical follow-up email assigning action items to the meeting participants. Finally, Blackboard also has a discussion forum that allows users to ask clarifying questions. This would directly benefit conference calls by removing the all-too-frequent clarification emails. Blackboard could be used as a tool to supplement a conference call, so none of it would occur in real time. This might make the less tech-savvy conference callers, such as Director Denise or Seasoned Sam, less intimidated by it. On the other hand, Coder Cathy might find this to be unnecessary extra features, as she has no trouble getting her point across during the meeting as is. A blackboard-esque tool for conference calls would primarily be beneficial after the call has ended. It could be a central location for any links, documents, questions, and action items. However, none of our users seemed particularly displeased with the amount of links/documents sent over chat, or the amount of follow-up required after the call ends. However, multiple users did express that they used email and IM in this way. Therefore, more user inquiry is probably required to determine whether or not these features would be used if they existed in a conference call app.
Instead of changing how we perceive/wish people to take or setup conference calls, it may also be interesting to further analyze how conference calls are used in certain rooms at a company. For example, a conference calling room for a 2 person meeting could be just a small phone booth-like area with available resources. This, however, would be pointless with a larger group that may have 10 people meeting with another 10 across the globe. Both solutions have their pros and cons, but ultimately there is no one choice for this kind of issue. On a similar strain of reasoning, we could also factor in current advancements in technology. Using a virtual reality headset might be a great way of simulating face to face meetings, without even needing a real room to meet. However, there are some cons to this. Our persona Director Denise may struggle setting up traditional calls, but with VR, it may be close to impossible for her to learn how to configure everything. On the other hand, Coder Cathy may feel very uncomfortable having a face to face, as she may lack the social skills to participate effectively. In the end, the trade offs need to be accounted for for each side, so as to provide a pleasurable experience for all users. Along with that, it is important to also consider the uses in each case. While VR would be cool and useful to make people feel closer, it would not help productivity if that required a person to type on their computer, or interact with the real physical world in any meaningful capacity. With our project, we need to think about how we can actually improve the existing meeting room, but we need to realize that new technology should be used with an explicit purpose more so than for the fun of it.
TeamSpeak channel window - this shows all the channels in a server, with which users are in which channels and some information about the users e.g. if they are muted. It also contains a chat and several toolbars for navigating
TeamSpeak is a service designed primarily for gamers to be able to communicate with other players on their team in order to coordinate activities in a game they are playing together. It is an interesting parallel to our conference calling system for a few reasons. Firstly, TeamSpeak contains separate interfaces for setting up a server and connecting to a server as a client, which mirrors our division between the person setting up and hosting a conference call and other people joining the call. This kind of division would allow us to put powerful controls into the hands of someone like Denise who would set up the meeting while avoiding cluttering the conference call itself with options that nobody except the host would use. Also interesting is the way that TeamSpeak divides the world into servers and then channels within servers. This maps fairly nicely onto a mental model of a corporation as buildings and conference rooms within buildings, which would allow for a hybrid style of conference where attendees either go to the correct meeting room or join remotely would be able to go to the right building and room physically, or would be able to connect to the right “building” and “room” remotely in order to join the call. All an attendee would need to know is where the meeting is and they would be able to join it physically or remotely. The remaining interesting point about TeamSpeak as it applies to conference calls is that it is really designed to run in the background with the main focus on a game. In a similar vein, our contextual inquiry has garnered some evidence that really a conference call is there to facilitate productivity and also should not be the main focus of the people using it. Right now, most conference calling systems we have looked at are intended to be the window in focus but it could be interesting to investigate alternatives such as an overlay or something else more in the background to allow conference call attendees to remain focused on whatever tasks they need to be doing elsewhere on their desktop. We will need to do more contextual inquiry and flesh out which personas we want to design for in order to see which of these ideas might be good for us to move forward with, but looking at TeamSpeak as a similar tool used in a very different context to corporate conference calling tools definitely gave us some ideas to consider when it comes to making a delightful conference calling interface.
Conference calling systems could have the power to make virtual collaborative meetings effective and efficient. Presently, too much mental energy in a call gets spent interacting with and attempting to understand the technology, rather than centered on the content of the meeting itself. A solution must address the need for a seamless virtual meeting environment in order to provide users with the feeling of technical competence and the freedom to focus on the meeting at hand. This would be characterized by reduced frustrations between the individual users and between the users and the interface, less time wasted finding and executing features, easy recovery and management of technical problems, and an engaging workflow that motivates productivity and focus. The benefits of a simplistic, intentional, and directed virtual environment for calls would ultimately be in increased productivity for the group within the meeting, and the increased feelings of competence and relatedness psychologically for the individuals involved.
Director Denise - Primary Persona - Strategy-Focused Project Manager
Denise is a technology literate and conscientious manager of a work group within a larger company. Her main dedication is to her team and her work. Given that her team comes from several locations of the company, she is responsible for coordinating conference calls for both check-ins and collaborative activities between the members. Denise thinks of conference calls as a way to get her team all on the same page. She is always in charge of assembling the agenda and establishing the call expectations, as well as leading the in-call meeting. She needs to know that everyone will be at the meeting and on time (even if she is late), and when in the conference call, she has to know about and be able to use all the features in case they become relevant or if she has to explain it to someone in the work group. She cares a lot about making sure that each member has an opportunity to contribute effectively to the meeting, which often places her in a position of eliciting people to talk, or having to choose who can speak next. She wants to be able to drive the direction of the team, make sure everyone is getting the right work done, and deal with anything that might be blocking her team members. She often has a physical notepad out to take quick notes during the meeting and has been known to share her screen or have other people present from their computers. She wants to leave the meeting confident that her team is on task and she knows any steps she needs to take to interact with other teams or deal with higher level business process that might get in her team’s way.
Angry Aaron - Secondary Persona - Developer
Aaron has been a developer for many years (10+) at the company because he enjoys the technical challenges of his work. He often works alone on his projects because it is faster for him to develop something alone than with a group. Aaron doesn’t like meetings. Aaron doesn’t like conference calls. Aaron generally doesn’t like people - at least people who don’t automatically grasp what he is working on with minimal explanation. He gets called into meetings usually as an expert in some area that the rest of the attendees have questions on. When he is in a meeting, Aaron likes to be able to focus on his individual work until somebody directly asks him for clarification or an explanation of systems on which he is an expert. He then needs to quickly get refocused on the meeting and have access to tools that help him explain his understanding to the other attendees. He wants to leave the meeting knowing that whoever he was talking to got what they needed from him and will not need to bother him again with the same or similar questions.
Coder Cathy - Secondary Persona - Developer
Cathy has been a developer at the company for a handful of years. She believes strongly in the company’s mission and has enjoyed working with her new team that Denise has been leading. Though she wishes conference calls could be easier for other members of the group, she finds them extremely useful for her work. Cathy uses conference calls to get feedback on what she is working on and guidance on what she needs to do next through action items the team develops together. She often is asked to screenshare by Denise in order to show everyone what she has done and jots notes about what they think, what questions they have, and what needs to be done next. She tries to vocalize questions she has about team directions she is unclear on, but sometimes feels that those questions might take away from the larger meeting. She wants to leave the meeting with a strong sense of what she needs to be working on next and where she needs to focus her efforts to improve the work she has been doing - sometimes that has meant emailing Denise to clarify what happened in the call.
Marketer Marty - Secondary Persona - Client Interactor
Most of Marty’s conference calls are with external customers, many of whom do not have much conference calling experience. Marty needs them to be able to navigate the system easily and follow what he is doing on the call. He also doesn’t have much technical expertise, so he needs to be able to follow the same procedure whenever he is on a call, otherwise he gets confused. He needs problems on the call to be easy for him and his customers to fix so they don’t get in the way of what he has to do. When he leaves a conference call, he needs to be confident that his customers are happy and that the experience they had on the call didn’t interfere with his ability to help them with whatever issues they were having with the product.
We also have a few personas that we are not explicitly designing for, but we do want to consider their needs in case we happen to be able to meet them easily without causing problems for our main personas. First of these is Intern Nelson. Nelson is an intern developer who is very confident picking up new technology but does not have very much to contribute to meetings because he is so junior. As such, he really doesn’t have very many needs beyond being able to join the call and maybe multitask on the side when he gets confused by conversations that don’t apply to him. A second persona is Grandma Gretchen. Gretchen essentially has no idea how to use a conference call, no matter how many times you explain it to her. As such, she needs everything to be as simple as possible just to get into the call, at which point other people on the call can talk her through what she needs. She also really doesn’t fall into the business use cases we are looking at so we don’t think she is that important. Finally, Seasoned Sam is a low-level manager. He has a hard time picking up new technology, so he tends to focus on the logistical details of a task. He has a hard time following conference calls, so he tends to stay quiet. He really needs to feel competent and important to the meeting.
Success might be best measured by a person leaving the call being asked how it went, and they respond with “Well....it was a meeting” rather than a commentary on call quality. A successful conference call experience should allow the actionable work to be able to get done at the meeting with all members having the ability to fulfill their role on the call.
Director Denise is the PM of a new product that her company is releasing. She has set up a conference call with Coder Cathy and Marketer Marty to discuss the direction that this product will take. Cathy is the primary developer of the product, and Marty will be troubleshooting the product with customers. She’s also invited Angry Aaron to the call because she knows he spent a lot of time working on a similar product last year, so she thinks he will have valuable advice for the team. Denise joins the meeting right on time, and is happy to see that everyone has already joined. “Is everyone here? Can you hear me” Denise asks. She sees that Marty is trying to respond, but she can’t hear him. “Marty, I think your mic is muted. Marty?” Marty’s video then disappears. “Marty I think you’ve turned off your video instead of turning on your mic. Try clicking that button again, and then click the one with the microphone icon on it. Oh, there we go. Great. Let’s get started. I’ll pull up the a powerpoint.” Denise successfully shares her screen so the others can see the powerpoint. “Wait! I’m lost. I don’t know where I am,” Marty exclaims. Cathy responds “It’s okay Marty- Denise just started sharing her screen so we could see the slides. Aaron, what do you think about the action items that Denise has listed?” There is a long pause. “Aaron? Are you there” Denise asks. “Oh, yes. I’m here. Um. Can you repeat the question?” Aaron responds, as he quickly finishes the line of code he had been working on. “Yes,” Cathy said, “what do you think about the action items?” “They look fine,” Aaron responds. “I might add one about…” The audio of the call cuts out. “Wait!” Cathy calls, “I missed that. The audio stopped working.” Aaron audibly sighs. “You need to add an item about testing the server to make sure it can handle the load. Also, it looks like we’re out of time, and I have another meeting to run to sooo…” Denise jumps in, saying “yes, thank you for your time everyone. There were several slides we didn’t get to today, but I’ll send out a follow up email with some notes and deliverables. Thanks everyone!” She hangs up the call.
Denise wishes there was a service for conference calls that would help the participants recover from broken technology, such as when the audio cut out. She also would like a service that allowed Aaron to be more engaged- she knew he was coding on his other monitor throughout the meeting, and wishes she could use his time more effectively. She noticed that Marty was quiet during the meeting, and wonders if it is because he was so confused by the number of features. It seemed like they spent more time debugging the system than focusing on the product. Why don’t conference calls ever end early like regular meetings sometimes do?
Conference calling systems could have the power to make virtual collaborative meetings effective and efficient. Present interfaces often get in the way of that by distracting the user with too many functions or alternatively hiding too many, assuming too much about what the user wants, and failing to be flexible to different productivity contexts. In initial user research, we discovered that our target market, people who conduct conference calls for business, valued having a context-driven, simple, and productivity-focused interface. From these interviews we distilled several personas which drove the development of the initial paper prototype. Director Denise, a semi-tech-savvy meeting host and moderator, has been our main focus throughout development. She cares about being able to explain an interface to others who may not be so quick to understand, having the meeting end on time, and getting every member of the meeting the information or action items they need in order to make forward progress.
An interface for Denise’s meetings must provide a seamless collaborative meeting environment in order to provide all members with the feelings of technical competence and the freedom to focus on the meeting at hand. Features in this interface must be clear in their intent, relate one-to-one with productivity tasks, not impose themselves onto the user, and be accessible.
For the purposes of developing this interface, we are assuming a web-based conference host can be used. We chose this mainly in response to the negative feedback we got around WebEx’s many windows that pop up. The interface will be focused on overall productivity through agenda management and workspace curation. Particular features selected to be available in this application include document sharing, document annotation, agenda management, chat, share screen, control screen, and video management. In our paper prototype phase we gave users tasks which mapped to the interface functions, and solicited feedback on feature accessibility and utility.
The interview brief for users included set-up, preparation, and in-meeting tasks. Set-up and preparation were largely scene setting interactions, in which there were one-button functionalities which were intentionally designed to lower the activation energy necessary to organize and join a call. In this phase users gave positive feedback about the one-to-one button to task design. Of the agenda screen in particular the largest flaw they saw, which was largely unanticipated by the team, was that there was no way to explicitly add documents. We had imagined that documents or links could be sent via the Outlook iCal, however, they explained to us the utility of having a pre-loaded conference ready with the information necessary to make the meeting productive.
In-call tasks included: sharing a screen with call attendees, giving screen control to a particular attendee, posting a link into the chat bar, adding an agenda item, checking off an agenda item, opening an agenda item workspace, posting a document, controlling personal sound or video, controlling an attendee’s volume, and ending the call. In this, users also enjoyed the one-to-one mapping we had developed between functions and tasks, noting that their personal preferences would lead them to use some buttons more than others. They naturally tended towards looking for document-oriented controls in the workspace pane, and call-related controls in the attendance pane. Additionally, the presence of the agenda was well received by all interviewed users.
The biggest flaw in our design thinking was in workspaces tied to agenda items. We imagined a world in which each agenda item would be distinctive from the last, meaning that a fresh workspace could be populated for each agenda item in order to clear clutter and refocus attention. We learned from our users that, realistically, this is never the case - agenda items often are on related topics, may include similar documents, be a part of a larger conversation, etc. Additional feedback we received was the need to provide as much real-estate as possible to the workspace, especially document viewers.
Following our interviews, we developed refined our thinking and paper prototype to reflect the most frequent observations we made about user’s interactions and their direct feedback. This included redesigning the meeting set-up page to include document and link sharing, and adjusting the main in-call screen to have a single context-driven workspace independent of agenda items. In this workspace, we modified the presentation of productivity controls to be as sleek as possible so to maximize the white space available for document viewing. A detailed description of our present paper prototype and interface workflow is provided:
The meeting organizer, from their Outlook calendar (as Outlook is a standard business mail managing tool amongst our users), creates a typical meeting request and opens our web-based platform with a designated button on the Outlook toolbar. This routes them to a page for conference call detail setup. Our setup UI allows the organizer to add agenda items to the call and add documents, something that all users expressed as critical during paper prototyping. The setup screen also allows the organizer to designate meeting requirements, and record the meeting. Both of these seem to be standard designations, which we learned from needs-analysis interviews. Once the organizer confirms the details, a link is created in the meeting request body, now ready to send.
Flash forward a week: the standard Outlook reminder window, now with an added “join call” button, pops up a few minutes before the call is supposed to start. Users can click this button to easily be navigated to the call in their default internet browser. This was modeled after very similar behavior that exists in Skype for Business. Users of Skype for Business really appreciated this feature, so we kept it in our design.
The user is routed directly to a prep screen which allows users to test their audio and video quality before joining the call, in addition to pre-muting and viewing who is already in the call. They can then join the call when they’re ready. Interviewed users valued avoiding the “Can you hear me?” moment that opens most conference calls, in addition to being able to sort themselves out before entering a call completely. This screen is a direct manifestation of these user values.
Once they have clicked “Join call,” users are greeted with a mostly-blank 5 section interface. These sections each offer different tools available to users:
In this interaction, our users needs are met by providing them a simplistic interface which as a group define based on meeting context. The challenge in designing an interface for conference calls is that individual interfaces have functions which are both local, and global to all other interfaces in the meeting - for example, individual controls for adjusting volume only impacts the person which used the function, however sharing a screen will influence how all other people wish to interact with their individual interfaces. Through a unified, collaborative workspace we have attempted to provide individuals a balance of autonomy and shared control.
Providing an interactive agenda management system directly addresses the need for productivity-focused calling. In the most basic use of this interface, simply the agenda, already each user has improved ability to follow with meeting tasks, relate tasks remaining to time remaining, and can contribute to the facilitation in the meeting. Then simple out-of-the-box functions like chat or attaching documents supplement this productivity mindset directly.
Our interface does not give an exhaustive number of collaboration tools for users, rather it can only highlight and comment. Creating a full-blown collaborative editor seemed to be unnecessary for most call uses, as determined by our interviews, but we acknowledge that in these situations, our product is not a suitable replacement for Google Docs or similar. Additionally, in the development of our interface, we have yet to test extensively recovery methods from dropped calls or serious time delays. In some ways, we have attempted to head the problem off with the well-received pre-join testing page, however, we have not provided functions to troubleshoot quality in-call. This did not come up with the majority of our users, and so we decided to focus our time in developing what did: the basic utility and functions available for productivity in a meeting. This was a trade-off based on user feedback and time allotted for the project.
This present interface rose above previously considered designs, including our first paper prototype. One idea that we initially considered and ultimately rejected was the idea of interface templating. Users could create interface templates that only contained features that they wanted in a conference call. This was an attempt to respond to the notion that individual users used conference calls in their own ways. Features that could be integral for one user are useless for another. We ended up rejecting this idea because it would prevent one user from walking another through some call feature, making them unable to help each other during a call. Additionally, users don’t necessarily know what features they will need before a call starts, making templating only useful given enough conference calls to determine what is “necessary”. For users like Marketing Marty or Seasoned Sam, the risk of creating a cluttered interface that interfered with productivity was too high.
A seemingly more promising design idea that we kept coming back to was one that facilitated the etiquette of an in-person meeting into a conference call, through functionality such as a virtual “raise hand” button. Several users, in preliminary interviews, indicated that one of their pain points in meetings was in how people talked over one another, failed to pay attention, or would frequently derail a meeting with interface questions. After talking further with users, and running our own conference call, we determined that etiquette could not be the focus of a conference call; that a system which helped to direct participants towards common goals would likely be more helpful than providing features that attempted to mimic in-person techniques for etiquette.
Another possible design we considered was a “virtual table” meeting, in which people could be “sitting” at a virtual conference table, and could raise their hands to speak. This was another attempt to introduce etiquette into a conference call and make it feel like an in-person meeting. This design was rejected when we realized that people inherently use conference call meetings differently than they use in-person meetings. This design was forcing the conference call meeting to feel like an in-person meeting, which actually in some ways reduced the utility of the conference call: it failed to scale with large groups, it would not allow for personalization or personalized control, and it made the call about the bureaucracy of taking turns, over getting a job done.
In each of these design rejections, and then the development of our ultimate paper prototype, we learned about how little value video actually has within a call. Initially assuming that conference calls were about humanizing people who are only accessible via telephone or email, we quickly discovered it was actually about skill and information sharing, and allowing multiple people to swiftly collaborate in real-time on a particular document, presentation, or decision. In this way, video was not a pivotal piece of the experience for users. Relatedly, conference calls are not, and perhaps should not, operate like in-person meetings.
Along the line of productivity tools, simple functions like chat, screenshare, and attaching documents are now so commonplace that users virtually identified them as “absolutely necessary” to have, regardless of whether or not they individually used them (though most did). Many other conference call products such as WebEx and Skype provide many additional features that few users told us that they used. Those that did use these more obscure features said they could never find them amid the rest of the obscure features. Our design eliminates these extra features, tending towards a more simplistic design with only core features. The only specialized feature we added was the agenda management bar, because as we discovered in trying our own meeting, and in talking to users, simply having a visible agenda can change the urgency and tone of a meeting. Having something to look at and ponder during a meeting instead of whitespace or video feeds changes the perception people have, as well as invites shared facilitation and ownership of the meeting.
Our users used “unified” and “personalized” to describe what they wanted out of conference calling interfaces. This makes sense with thought: users want to be able to have individual control of what they are doing, but want to be able to see what others are seeing. Creating function-linked unification and personalization was a way in which we attempted to strike the balance for our users. They have the ability to use most features in the way they want to - they can view documents when they want, add comments, post to the chat, change volume - but when all focus is on a particular group action like screensharing a presentation, a unified interaction is initiated.
In moving forward, armed with these insights and the latest paper prototype, we will be conducting several more user interviews so as to completely prove the workspace and workspace bar interactions we have developed. We anticipate that the layout of the workspace bar could change following these interviews. This next phase will be focused on the development of wireframes to further test the aesthetic design of our interface and explore more virtual expressions of feedback (like glow, color, highlighting, graying).
There are three main screens in this application: the Scheduling Assistant, the Pre-Join Screen, and the In-Call Productivity Space.
The Scheduling Assistant, accessible by the Outlook Calendar integration “Add Conference Call” button, offers the key features of task addition, document addition, indicating whether to record the call, predefine call requirements, and confirm the details of the meeting. Adding a task causes a small pane to appear on the screen in which the users can add details including task title, task details, or document to associate with task. Users can discard or save each task. Similarly, adding a document allows a system window to pop-up, letting the user select their desired file. Requirements of the meeting are saved in the system and later populate as defaults in the Pre-Join Screen (for example, there will be a video tester if video is required) or expressed to users in the link that is put in the iCal invitation (for example, “Sharescreen will be a functionality that will be used in the meeting”).
Once a user confirms the details, a hyperlink with message is posted in the iCal invitation. When meeting time comes around, a Join button will be available on the reminder screen which accesses the link, thus opening the person’s internet browser to the Pre-Join Screen. On this screen, a user can mute their microphone, turn off their video feed, see who is already in the call, and join the call. A message indicating whether or not the meeting is being recorded is also provided.
Clicking “Join Call” sends the user to the main Call Productivity Space in which they are one of several participants, viewable at the bottom of the screen. In this Participants Pane, a user can unmute/mute their microphone, turn on/off their video, maximize the video of other participants into the Workspace Pane by clicking on them, adjust the volume of other participants, and end the call.
Users also have a shared agenda pane in which any individual can add an agenda item or check-off an agenda item. This is a scrollable pane for long agendas. Adding or checking off an agenda item is a global change, which means that individuals will see results of an individual’s additions or check marks on their agenda panes.
Passive elements like a title bar and timer are also available for users to view.
The Workspace contains a feature bar, listing (from left to right) Chat, Share Screen, and Documents. Clicking on the chat button causes the tab to slide up, revealing a global instant messenger with typical controls: typing in a text box, pressing enter to send messages. This can be minimized by clicking on Chat again. For users that have the chat window open, new messages will simply appear. For users with the chat window minimized, they will get a small indicator posted onto the button, showing the number of recent messages.
Clicking in the Share Screen button changes a user’s video feed into their desktop screen. This becomes instantly viewable in the workspace by other participants in the call, however it does not close any previously open windows underneath. The screen-sharer also has a new function: Give Control. Clicking on this button causes other participants in the Participants Bar to glow. Selecting a participant gives them control of the screen-sharer’s computer. This is indicated to the controlling user by a text indicator and glowing mouse. The Give Control and Screen Share buttons change to End Control and End Share respectively. When End Control is clicked, the controlling participant no longer glows or has control. The End Share is clicked, the original video feed of the sharer is restored, and the video feed is minimized for other users.
Posting a document, by clicking on the + button and selecting a file from a normal computer file system window, will cause the file to be added to the call’s document cloud. The document will become accessible to all members on their Documents section. By clicking on the document title, the document will open in the workspace of the individual user. Clicking on a document does not open it for all other members. When open in the screen, the cursor changes to a highlighter pen. Clicking and dragging causes the areas touched to change colors, to indicate highlighting. Releasing the button causes a comment bubble to appear in which a note can be typed. A blank bubble will simply disappear.
To end a call, the “End Call” button can be selected, or the internet browser tab could be closed. In both cases, the person who removed themselves from the call will disappear from the participants field for other users. When the last participant leaves a call, the cloud documents and agenda are captured and saved to the original conference link. When a user re-visits the link, the saved information will be accessible.
In this activity, we will be walking through the creation, joining, and experience of a conference call. We have a series of tasks to make your experience more goal-oriented, and we look forward to your feedback. We also want you to keep in mind that Team Room is designed for professionals who work on teams and generally have conference calls in order to communicate about and/or collaboratively engage in the work the team has to do, so try to put yourself in the shoes of such a person if you can.
You’ve already started an iCal to invite your coworkers to the meeting for budget review. You would like to link directly to the calling service.
You’re now in the Design window of Team Room. Please name your meeting, list an agenda item for this budget review meeting, and attach the budget file. You may choose whether or not you would like notes to be sent to you following the meeting. [Please note: in this prototype, only two agenda items and one file can be added on this screen. The full prototype will allow for more.]
After reviewing, you can choose to create your meeting. A pop-up should appear, which will link you directly to your call and offer to place the link within your iCal.
Before your meeting starts, there will be a reminder that you need to join in. When you see this reminder, join the meeting, test your audio and video, and enter the call.
You know that you need to talk about why the dinosaurs became extinct later in your meeting to ensure that your company budget does not meet the fate of the dinosaurs. Add an agenda item now to make sure that gets covered.
After your fascinating talk about dinosaurs, you’ve realized that your company needs to build an asteroid defense system in order to keep the budget from being destroyed. Make sure everybody else in the meeting knows that this agenda item has been completed.
In order to build that asteroid defense system to protect the budget, it needs to be in the budget. You should open the budget, review the items there (perhaps commenting or highlighting various points of the budget), and add the new line item for the rest of the group to see.
In discussion over the new line item, someone asks about the likelihood of an asteroid hitting earth in the near future. Conveniently, you had just finished the spreadsheet on these probabilities, so you add the file to your call, making it accessible for discussion.
Pip, a PETA member, is very distressed over the budget item around hamster-driven warp drives. He starts getting louder and you don't want to hear him. What can you do about that?
All this talk of hamsters reminds you of the hamster-powered hacks you’ve watched on YouTube. Sensing the need for levity in the meeting, but also making a point about hamster happiness when scurrying doing useful work, you decide to post a link in the chat to share with everyone.
The conference has drawn to a close. Leave the call.
Conference call experiences need to be focused, simple, and seamless. The TeamRoom interface provides an environment where teams can work together seamlessly to not just organize and plan work, but get it done.
The user begins by setting up an ical for their meeting. They can choose to add a conference call to that ical, which brings them to the Design window. Here, users can name their meeting, add tasks to their agenda, and add files to their call. They can also choose whether or not their call will be recorded. After hitting “I’m all set,” the link to their conference call is added to the ical, and they can send it.
When the time of the call approaches, Outlook’s reminder pops up, and the user can join the call directly from that reminder. They are taken to a call testing screen, where they can confirm that their audio and video is working properly, as well as see who is already in the call. This is also the screen where the user sets their name. When they’re ready, they can click “Join Call.”
From the call screen, users are able to add and check off agenda items, chat with the other members of the call, and mute their microphone/video. They can also adjust the volume of the other members of the call. Users can also open, highlight, and comment on documents from this screen. Finally, when the call is over, they can end the call.
A few aspects of our design changed as a result of our user testing and our cognitive walkthrough. During our cognitive walkthrough, we realized that we had never given the user the opportunity to enter their name into the call. We added this into the prototype. We also found that we didn’t have any way to edit or delete agenda items. We decided to add editing functionality to resolve this. During our user testing, our primary realization was that there was some confusion around the “meeting requirements” section of the meeting setup page. None of our users really found it necessary, nor did they understand its functionality. However, it did lead to the idea of adding files to the call on this same page.
Throughout our design process, we had to make some compromises, both because of time constraints and design limitations. One of the main categories of tradeoffs that we had to evaluate was caused by our tool choice where we implemented our prototype. Axure is marketed as an “interactive wireframe software and mockup tool.” What this meant for us was we could quickly and easily layout our prototype and add functionality such as changing screens and live video. What this also meant was we had to adhere to the built-in system, which was not always the most extensible. This sometimes meant we had to make do with less rather than more.
One example of dealing with less rather than more is when creating a meeting, a user is only able to add two agenda items. It still gets the point across, however it probably is not enough for the real world. Along similar lines, some of our features from the paper prototyping phase did not make it into the main prototype. The features that were impacted were the timer for the meeting, and the ability to share one’s screen. For these features, the time cost to implement them would have far outweighed the usability that would impact the prototype. For this reason, they were left out of the initial prototype. Another consequence was the video system we decided to use. Because of the video interface, we were unable to implement volume sliders to control other users’ volume levels. Muting audio and video is handled within the system, but there is less customizability and the system will be evaluated to determine if it is the best option moving forward.
Finally, we compromised in the sense of using pre-existing systems rather than reinventing the (possibly worse) wheel. We used Google Docs in an iframe to show how to collaboratively edit documents and have multiple participants join in live in a possible meeting. This meant that our system in the paper prototype of commenting and adding notes to a document was absent from the final prototype because Google handles that system already, and they do an excellent job. Our overall rationale in this regard was “Google is leading the field in this category, so why implement something that will definitely be worse.” With our current implementation, we saved time by reusing a pre-existing system, but modifying how it might be used in a meeting instead.
Before our evaluation, we had made several intentional design choices which aligned with the 10 heuristics from Nielsen. This ranged from simple page labeling or color indication on clicked items (visibility of system status) to frequent opportunities for a user to edit or “change their mind” (user control and freedom). One of our key design decisions was to map our interface to a conference room - we have a “whiteboard” for posting documents and working together visibly, we have a “table” at which all participants “sit,” users enter the room, etc. This language reflects in-person meetings, making the app approachable, however we recognize that a virtual conference call is not the same as an in-person meeting and there should be some allowances for an individual. To this end, we have made the system aesthetically minimalist and flexible. A user may self-populate their own whiteboard and that is private to them. The tools available to the user are limited to the necessities, including SMS chat, document share, video/audio. A summary of our design choices as related to the heuristics can be found below:
Reflecting further on our design decisions, we notice that the mapping of room to app is particularly compelling. In our Hierarchy of Needs discussed at a previous date, we recognized that the desire for efficient and effective meetings is built upon the feature set of the meeting, and this included the space in which a meeting occurred. Meetings in physical spaces bring people together face to face and provide access to visible, common resources. Teams can own the space in which they are physically meeting, if temporarily, and this creates a feeling of meeting ownership. Other needs of our users - Cathy’s desire for relatedness, Marty’s desire for ease, Denise’s desire for everyone to feel confident - they can all be obviously addressed in a physical meeting. By manifesting these feelings and features in the application, we hope to improve the experience of virtual conference calls.
Following our heuristic evaluation, we feel confident that our fundamental design decisions - the mapping, the layout, our feature set - are understandable. The criticism of our application stemmed from some of the limitations of our prototyping tool, Axure, which impacted the aesthetic of the design, the ability for users to add multiple tasks or agenda items, etc. Other criticisms which included the font sizes, availability of help text, lack of guidance in the lobby, were simple oversights by us during the design process because we were so fully engaged in developing the prototype. All of the major criticisms seemed to stem from a desire to make the interface more legible or immediately understandable instead of implied. In example, giving simple directions on the lobby screen would help a user know how to adjust their system and know the consequences before entering the meeting. At present, all of the consequence is implied, rather than immediately obvious.
There are a few changes we knew we needed to make before our heuristic evaluation feedback. Many of these revolve around the table area of our design and issues surrounding the video system we used in our first prototype. Right now, we do not get the seamless experience we are looking for with video, as users need to join the video after joining the call when they should be able to just join. Additionally, the controls they have are limited by the third party tool we are using and we want to allow them to control the volume and positioning of the other people in the meeting around the table. We also want to make some adjustments around the number of people in the meeting, as the table is only large enough to seat 4 people comfortably at the moment, and we are looking for a way to expand it, perhaps with a horizontal scroll. Fullscreening the table or an individual at the table may also be something we should pursue although we would like user recommendations about that option.
Another area we need to work on is our feature selection. We are currently short a few features we were hoping to have and we want to make sure that adding them back in does not complicate our interface too much. Specifically, we know we need to add in screen share and control share for users like Marketer Marty. We hope that with some changes we will be able to expand the flexibility of Team Room without sacrificing the seamless experience and technical stability that serves as the foundation for any effective meeting tool.
We also received a number of suggestions from our heuristic evaluation that we plan to implement in our final prototype. Several of these suggestions revolved around the aesthetics of our current prototype, as we did not focus on making our visually pleasing or consistent in this iteration. This will certainly be a focus of our next iteration. We also learned that the navigation flow through our design was not as natural or intuitive as we had hoped. We plan to revisit some of our design decisions to see how we can increase discoverability and understanding of our different features.
Following the heuristic evaluation, the team has spent time adjusting layout and visual aesthetic of the prototype. Using Axure, a wireframe prototyping software to make click-through interfaces, we attempted to address the concerns raised by the heuristic evaluation, as well as execute on intended changes outlined in the previous section.
Direct Response to Severity 3 Items
Also raised during the heuristic evaluation were small adjustments to the experience. One such suggestion was the deletion of the pop-up with meeting link following meeting design/set-up. We had initially included this page because we wanted to give the user an opportunity to preview the room before finishing the set-up of the meeting. Our evaluators indicated that they were confused as to the option - was it to share with others? Was it to click? Our solution, upon reflection on the utility of the pop-up was to delete it. A link to the meeting is populated within the iCal directly, which can be clicked by the meeting designer in order to enter the room or can be copied and shared in another format if they so desire.
A consistency concern with whether to use the “Enter” key or click on a button was also raised. We had unintentionally used different standards. This is addressed by providing a clickable “enter” option to all editable fields. To aid, we will be adding some “hover-help” alt-text to features to explain their use.
We also added better and more specific labeling language throughout the prototype. To this end, we now specify the type of material that will be provided to a user if the call is provided. Next we add better symbolic labeling to “Add File” within the main call screen. Upon main call screen loading, we provide instructions on the WhiteBoard to better inform the user about use in the prototype.
Last, we have added a Share Screen button, and a Share Screen experience for the users. Though logistically sharing screens is challenging with this prototyping tool, this is a feature we felt strongly would be included in a true prototype. To this end, we attempted the next-best experience which is being on the receiving end of a share-screen. This also leverages another feature we are rolling out, which is video screen enlargement on the WhiteBoard.
All of our changes can be viewed at our new and improved prototype: Available Here