MICROSOFT TEAMS: CREW COMMUNICATION
Consolidating conversations across multiple platforms into a single tool
Between longer legs of travel, crews have to find accommodations and make dining plans. Many times, they will spend off work hours together as they wait for their next flight assignments. Crew members can arrive on different flights and at different times. Hosting that conversation in a central location facilitates and encourages those interactions improving the overall experience.
PROBLEM
Crew members use social media apps and 3rd party products instead of the company portal to plan and converse
PROJECT TIMELINE
3 Weeks
ROLE
• Designer
TOOLS
• Sketch
Design
This design process began by defining guidelines impacting high-leve design decisions:
WHAT A comprehensive chat tool with role based access
WHO Any flight crew members
WHY Decisions can be made ahead and information can be easily shared
RESEARCH AND ANALYSIS
The client, a well known airline company, uses an employee portal where flight crews perform administrative taks. According to provided data — even though the fucntionality exists — employees rely on other chat or instant messaging services to communicate with each other. This results in errant conversations, reduncancy, and unshared valuable information.
TECHNICAL RECOMMENDATIONS
It was suggested that the client transition to Teams and make the portal it's primary application. The portal could be permanently pinned to the app bar and always accesible. Users can still perform tasks in the employee portal but would also have access Office 365 apps. This would create a seemless integration between the two products.
USER FLOW
This scenario features Teams as a collaborative hub. With the portal always accesible in an iframe, we took on the issue of funneling conversation back into a central location without losing privacy controls. With Teams, airline employees could have public and private convserations, group chats, and access shareable content.
Digital Wireframes
1. The bot creates a new team and injects a card into the channel with information about the flight
2. The user clicks the Crew button opening a modal with a list of the flight crew
3. They select a crew member from the list and begin a 1:1 chat
4. From the initial card, the user clicks the Layover button. A new card is sent with layover options
5. Dining is selected and modal opens with options for users to vote on, keeping the thread clean
6. The tally resolves in the Layover card and update as each member submits their vote
7. Using the bing search engine API, an atlernate user finds additional restaurants and votes for one
8. The Layover card is updated and the search results can be retrieved in the app's message extension
9. The second user selects and shares the restaurant's information as a card directly into the chat
FINAL SCREENS
I created the high resolution mocks in Sketch. The final screens rounded out the narrative, fleshing out details of how each step would appear to a user. The customer was very happy with the results and they began building. Click here to interact with a clickable protoype
Final screens:
Automated creation of channel and team by Bot
Crew manifesto with embedded chat ability reducing number of clicks
Adaptive card with tallied votes prevents channel 'noise'
Card in compose box with data retrive from message extension
MOBILE SCREENS
Many crew members prefer their phone over a laptop while mid flight. Since flight crews and schedules change constantly, it was important to provide mobile views to ensure everyone could participate and share.
Mobile screens:
Lock screen notification
Adaptive card send by bot
Flight crew roster
1:1 chat between crew members