WIKIMEDIA

Task: Bring 47 million multimedia files from archive to users

My roles: Researcher, wireframe/visual/prototype designer, presenter

Overview

The brief posed to our team of four was “find a way to leverage Wikimedia's 47 million multimedia files and make them accessible by everyone in the world.” Our solution was a multimedia-browsing app with a focus on objective material and some extra features for quick information retrieval. 

Discover & Define

We conducted a screener test of 83 participants which lead to 12 user interviews and 1 contextual inquiry.

Some of our findings:

“I’ll use my phone to verify stuff or reference something in a conversation — the important thing is that it’s quick.”

When checking the validity of something using an online reference was the frustration at lack of reliable material. Youtube is clogged with crap. Vimeo is too artistic. Users needed something in between.

70% of internet use occurs on mobile so effectively searching on the move would be crucial for the platform. More serious users tended to begin their search at Wikipedia before spring-boarding to more highly-regarded sources they could rely on and potentially cite.

Develop & Test

We decided to design mobile-first and build an app for Wikimedia, based on user demographic and time constraints. Mobile-first is also a great way of keeping things simple. 

From this, we went with a simple homepage with a clear search>results feature, which was heavily influenced by Pinterest and their dual-column multimedia list since we liked the potential to display several types of files.

Membership was not immediately a concern, since our research showed most people did not massively mind about it. We also omitted commenting, as research showed that this seemed to invite an element of opinion that did not suit the Wikimedia brand or the spirit of the app as an objective resource.

Key findings from the first and second prototypes included…

  • Non-English speakers felt their lacked an obvious language button

  • Categories on the search page were basically useless. We swapped these out for previous search terms instead.

  • We added the ‘chapters’ feature, where the uploader of the video can choose particularly good points in the video that a viewer may want to jump to.

 

Outcome

Visually we tried to stick as close as possible to the Wikipedia app so that the crossover for current users would be seamless; this meant the Wiki colours and Linux Libertine font to retain the Wikipedia DNA. We also used a good deal of the Google Materials design approach for clarity.

Below you can see some final screens from a key flow, plus a stretch feature we added toward the end that randomises the image/video/audio clip the user experiences by tapping a dice icon.

 

Conclusion

Besides the visual design, the element of the project we agreed was a success was the scope of the user base; this could be an app for everyone . Anything approaching objective material is hard to come by on the internet, but if any top 10 online company can bring that dream to life, it’s Wiki.

 

Feedback was positive; the last round of user testing was encouraging in terms of flows and visual feel, one user told us:

“This is a great vision for what the Wikimedia app might look like”.

If we had more resources (mainly time) it would have been great to explore and iterate the ‘randomise’ function a little more and try out some contributor flows.