Mobile App Information Architecture
Updating the UI in the user profile will have little effect if a larger information architecture problem is not addressed.
Moodle Mobile App
Perth, Western Australia – December 2016
The Moodle project is a free, open source, web based learning platform for educators, administrators and learners.

The Moodle project is led and coordinated by Moodle HQ, a small Australian company supported financially by a network of over 80 Moodle Partner service companies worldwide.

The Moodle Mobile App for iOS and Android is a free companion app to Moodle and is available on the App and Play store. The app is dependent on the user having a pre-existing user account on a web hosted Moodle installation.
Business Problem
The Mobile App product owner identified the user profile section in the Moodle Mobile App as an area where the UI had not be updated for quite some time and was due for a refresh.

Business requirements were based loosely on contributions from members of the Moodle open source community that emphasised the more utilised actions, such as messaging and email with a stronger design treatment.
Constraints
No Tracking & Reporting Data
Due to the open source nature of the Moodle project and the companion mobile app, usage data and analytics are not available due to strict restrictions on user privacy and self imposed limitations on user data collection.
User RESEARCH
Improvements to Messaging & Email are important to Students & Teachers
User feedback from recent surveys of the open source Moodle Mobile App community showed that improvements in email and messaging are important to both students and teachers using the mobile app in the higher education sector.

A user research card sorting study (with the goal of gaining insight into overall Moodle feature usage patterns) from the larger open source Moodle community had also recently been conducted. This card sorting study also reflected that messaging (email included) is a feature that students and teachers "use all the time."
Success Criteria
Ease of Use as an Indicator of Success
With no tracking data or other analytics to reference, we proceeded with updating the user profile UI with future usability test results as an indicator of success. By conducting various rounds of usability testing, we would observe how successful participants were in attempting to message and email other students through the user profile view.
Design Assumptions
Optimal Solutions for Common Problems
  • 1
    Hierarchy of Importance
    By displaying the messaging and email features first and de-emphasising and moving the lesser utilised actions of blocking and removing a contact to the bottom, we would create a clear hierarchy of importance to the user.
  • 2
    Clear Distinction of Actions and Navigation
    By treating the secondary features of the profile section such as about, grades and badges as navigation and not as an actionable button treatment, we would make a clear distinction between the two functions.
  • 3
    Familiar Design Components
    There's no need to reinvent the wheel. Save time and effort by taking advantage of the ready-made, cross platform Ionic components and frameworks the Moodle Mobile app is built on.
Results
Usability Testing Revealed a Large Gap in the Information Architecture
To validate our design assumptions for user profile, a rapid prototype was built using Invision and unmoderated usability tests were conducted virtually through UserTesting.com.

The team was happy to see that usability test results were positive and our design assumptions for the user profile UI were generally correct. But an unexpected observation was made while we watched users attempt to complete the tasks we had set for them. Users were unsure and not confident on how to even access a classmate's profile after launching the app from the home screen.

Usability testing revealed that the existing flow to access a classmate's public profile page was not intuitive. The user's first instinct was to take a completely different path from the existing one, which resulted in confusion and some users not being able to complete the task successfully.

The current profile flow assumes the user knows to navigate to a specific course to find the contacts/participant list.

We could assume that a new "Contacts" menu item in the app's side drawer that navigates the user directly to a list of course contacts/participants would eliminate confusion.