United in Support of the UN: A (Special) Case Study

Matthew Johnson
7 min readOct 29, 2019

--

My team shows off an LMS prototype on Axure.

Introduction

This was a special assignment for a special client. The specific office will remain nameless, but I was recently authorized to disclose that my work was conducted on behalf of the United Nations.

The basic objective was to develop a learning management system (LMS) from scratch — for desktop and mobile — based on current best practices and client specifications. We focused primarily on information architecture, which comprises the structure and labeling of web-based content, because our client requested that the LMS be flexible and customizable yet straightforward enough to function in multiple languages and contexts. The minimum viable product needed to include training videos, webinars, a dashboard or homepage, and a means of communicating directly via forum or chatroom. High-fidelity prototypes that included these features, modular design patterns for easy replication, and recommendations for future improvements were to be our main deliverables. We were not given much direction on what content would ultimately be added to the LMS, but we were told it would include training and resources for addressing internal conflict.

After a brief summary of our process, this case study will cover the following:

1. Research

2. Design Studio

3. Wireframing & Prototyping

4. Usability Testing & Iteration

5. Roadmap & Recommendations

Visuals will be added to elucidate key aspects of the process.

Our Process

The duration of the project was just over two weeks (from initial briefing to product handoff). The three of us documented our progress daily and made note of any concerns or stumbling blocks. The majority of our time was spent on wireframing and prototyping. We shared frequent updates and epiphanies through Slack and worked simultaneously where possible, even remotely, using Miro, Creately, and Google Docs. We also consulted tutorials and outside authorities when necessary.

Research

Our research for this project can be divided into three main areas: 1) Use cases, 2) LMS comparative analysis, and 3) Task analysis. It was a challenge from the beginning to start where a good UXer should — with empathy for the user — because we did not have any direct client contact. (Our briefing came in the form of a document provided by our professors, and we received only small bits of additional information). We understood the organization well enough based on its reputation and a little secondary research on its values and hierarchy but struggled to identify typical use cases for the LMS we were tasked with developing. We compensated for this deficiency by talking to people who worked at comparable organizations (without disclosing our client), understanding their learning needs as employees at said organizations, and adjusting our use cases accordingly. Otherwise, our use case scenarios would have remained entirely theoretical, and we would have run the risk of developing an LMS that did not solve the right problems.

In order to design any LMS at all, though, we needed to know what the typical LMS looked like and felt like. All of us were familiar with Canvas, Teachable, and a few other platforms from past experience, but it took some Google searching to find the top learning management systems on the market and compare their features. We took a closer look at the features requested in the client brief and how they functioned on those (pre-existing) learning management systems in order to inform our (future) wireframes. We listed out all the features we intended to include — but later shrank the list so that we could focus on the minimum viable product given our time constraints.

The next step was to understand the connection between information architecture and usability in the context of an LMS. We conducted two task analyses with real users of similar learning management systems. We took note of how they accomplished comparable tasks to those of our client’s users — namely enrolling in a course, searching for a particular course or webinar, or posting a question to a forum. We also noted any pain points or long delays in the process of completing a task and asked clarifying questions. Our main takeaways were to minimize the depth of navigation to no more than three levels and to provide multiple pathways to complete the most important tasks.

Design Studio

During the first week of the project, our professors set up a design studio based on methods developed by senior UXer Todd Zaki Warfel. We started with a specific problem that was central to our LMS design and sketched multiple solutions individually. We then shared those sketches with the team for a round of critiques, repeated the process (with revisions), and, lastly, converged on solutions. The design studio is an Agile method operating on the premise that multiple iterations and team collaboration result in better solutions. At the time we were still trying to visualize all the building blocks of the LMS — some of which we later realized were not a high priority given our time constraints — so many of our initial sketches were discarded.

My team shares early sketches of desktop and mobile MLS.

After the design studio, we decided to focus on our sitemap and global navigation bar, which we would alter a few times in order to reduce both the depth and breadth of navigation. The global navigation bar remained more or less consistent as we expanded our sitemap and proceeded to wireframing.

Wireframing & Prototyping

We were instructed to use Axure as our primary wireframing and prototyping tool, but we continued to sketch by hand until we went through enough tutorials, tinkering, and instructor-led workshops to feel comfortable. One team member designed wireframes in Marvel for the dashboard and training pages before learning Axure. A lesson in atomic design helped us break the challenge down into smaller pieces to ensure that we did not reinvent the wheel with every page. We then built a pattern library that included the atoms, molecules, organisms, templates, and (modular) pages we used.

A later lesson on best practices for mobile design led us to maintain the same modular structure while adjusting the size and quantity of items to fit a much smaller (iPhone) screen. We began with the desktop version because learning management systems are typically intended for dedicated, sit-down learning and not on-the-go learning. They also tend to be web-based and not app-based. Nonetheless, our client requested that our prototype function on desktops and mobile devices.

Low-fi Marvel wireframe of dashboard
Low-fi Axure dashboard page template
Mid-fi Axure dashboard page (desktop)
Mid-fi Axure dashboard page (mobile)

Usability Testing and Iteration

We conducted five usability tests including a walkthrough with our instructor. In the early stages, these tests led to changes such as the inclusion of a drop-down menu to sort through content rather than listing topics in an inconvenient location (on the Forum, Training, and Webinar pages). We were also compelled to change the name of the “Classroom” page to “Meeting” to better describe its intended use. Later tests helped improve the wording of menus and the use of labels to identify different categories of content. Most of the global and secondary navigation was intuitive to users, so we made few adjustments in these areas.

The feature we adjusted the most was our most unique one: our “assist” feature, which suggests items (webinars, training videos, and forum posts) based on what users select as their most pressing need from a drop-down menu on the dashboard. Initially this feature was more of a check-in on the user’s emotional state to ensure that they felt safe using the LMS as a resource to address major conflict and not just to handle more mundane issues. Our problem was that we had no clear way of curating training and resource recommendations based on the user’s reported emotional state or mood and, therefore, ultimately viewed the feature as an unnecessary, non-functional inquiry. Our tests reflected our concerns, so we ultimately settled on the question, “How can we best assist you today?” and a drop-down-menu list of options.

Close-up of the dashboard “assist” feature

Roadmap and Recommendations

We documented our workshops, tasks, and technology used throughout the project in the form of a project roadmap while projecting into the future (in the form of a product roadmap). Finally, we offered general and page- or feature-specific recommendations to our client.

Our top recommendations for the next phase of the project included:

  • Determine top workplace issues for Assist Feature
  • Specify topics for training, webinar, and forum pages
  • Allow for sorting by said topics

Farther down the road, we recommend:

  • Gamification (scores, leaderboards, etc.)
  • Accessibility audits
  • Transcripts for all videos
  • Connection to a chatbot
  • Private login
  • Admin options
  • Anonymous posting

--

--

Matthew Johnson

I’m a meticulous scholar, creative problem-solver, and passionate advocate whose bottom line is unlocking human potential through writing and research.