mobile portal
overview
Final context scenario showing access in various campus locations throughout the initial use. As being an 'ambassador' can still feel murky and vague, we wanted to ensure growing confidence and ease.
problem as presented
The client wanted a scalable and measurably effective support community for its student ambassador program. Ambassadors only work a few hours each week, but are responsible for increasing brand awareness on campus through product demos and other activities.
concept
We reframed the original problem by addressing an underlying need. Our concept, the MATLAB Ambassador Portal (M.A.P.), helps student ambassadors plan events, promote the brand, and connect with the student community. It takes advantage of in-between moments, helping ambassadors easily switch focus to an infrequent responsibility and get more done in less time.
my role
I was the team's primary point of contact for this remote Emerging Interfaces course project. I also contributed equally to the research and design process up to the final prototype, which one member executed with input and feedback from the rest.
understanding the user and the problem space
These early sketches show some key ambassador frustrations - overwhelming amounts of information, a user community unfriendly to learning students, logistical challenges - and how a helpful IUI might mediate those into a more positive experience.
research methods
For this project, we conducted interviews, performed a competitive analysis, and used analogous empathy. We interviewed people from a variety of engineering disciplines, including an official MATLAB student ambassador, other university MATLAB users, and professional MATLAB users who represented the downstream effect of campus programs.
We learned that event planning is not a natural fit for engineers, and, with limited time and aptitude, ambassador duties can feel overwhelming, isolating and frustrating. Our student ambassador also pointed out that campus bureaucracies made event logistics challenging. And we learned that professional communities are not particularly friendly to student learners.
Our system persona explored the perfect ambassadorial assistant to an engineering student. When we boiled the tasks down to just the most essential and re-examined the scale for this project, we realized we did not need to go that far. We did keep helpful, right-time-and-right-place attributes in the interface's posture, however.
personas
With the research and the original problem in mind, we created three main persona types: ambassadors, MathWorks administrators, and undergraduate MATLAB users. We also created a system persona to look at the problem from that angle.
task and contextual analyses
We spent much time "exploding and compressing" the defined ambassador responsibilities, looking at various ways the different personas interacted with each task. Through these analyses, we determined that automating and streamlining event planning responsibilities would provide the ambassador the most value.
This version of the task analysis was too complicated, but it did help us see the intersections of all three personas with the tasks. The big bubbles are different situation/need contexts, linking back to key points in the overall event flow.
As we simplified our tasks and workflow, we simplified our wire frames through various desktop and web versions. It was an easy step from the last card-type Balsamiq version to mobile. The left image on the bottom also a view a student attendee might see and provides access to sharable parts of the ambassador's event kit.
design process
sketches/wire frames
We sketched several short interactions, looking to discover key emotions in specific contexts. By placing our ambassador persona in context, we realized that our first intent – a desktop application that would plug into MATLAB – was the least likely scenario. At that point we switched to a purely mobile design for the student ambassador, and also limited our scope to the ambassador role.
conceptual models
Almost final architecture, showing how the three main containers relate to each other. Ambassadors and students come in at the "My" level, with personalized information based on role, major, event attendance, or custom groupings.
It wasn't until after we switched to a mobile POV that we started to solve other problems. We narrowed our focus to the most important tasks. We realized we were all using different language, and clarified our architecture once we clarified our semantics. We also finally understood the role community played in our application, and instead of either ditching it completely or leaving it as a disconnected add-on, were able to fully integrate it into our model.
final prototype
In the final prototype, we decided that the to-do list would most likely be the first go-to screen for ambassadors. All necessary tasks are contained here, and they easily connect to other places in our architecture (the event kit Library during the “Plan an event” task, for example). Swiping left and right are standard mobile features, and the card-type interface provides both a consistent look and a consistent interaction throughout the application. Users are placed into community groups automatically through demographic data and their RSVP interests. Widgets allow ambassadors to customize their experience and workflows.
In the final prototype, we made one adjustment to our architecture and split out scheduled events from the event kit library. This is a sample of our final working screens, from the to-list at the left, through a task, into the scheduled events list, with detail of the kit, and ending in the community..
evaluation
challenges
There were many ways to approach and solve this problem and so we struggled to initially find our way. It was also difficult to not have access to the specific target audience to test our concept or clarify questions. We made a big assumption when we proposed the idea of pre-populated 'event kits' as a way to both simplify the work of the ambassadors and provide a measure of quality control for the brand.
Finally, as we were all remote from each other, it is unclear if this aided unity and dialog or abetted cognitive dissonance during the process. We rarely used our cameras to see body language or facial expressions, instead focusing on the drawings, sketches and prototypes we were discussing. It was essential to listen carefully to tone and inflection, and ask many clarifying questions.
lessons learned
I think we were all surprised at how difficult a seemingly simple problem could turn out to be. What saved us was that we really threw ourselves into the design process, and continually pushed each other and our ideas, asking 'Are we looking at the right problem? How would Sam/Casey (our ambassador personas) use this? How can we make it even simpler?'