Improving the usability of the Wiki for students
StudentWiki aims to be the go-to portal for students to get the perfect summary for their course. I'm responsible for the end-to-end product design.
Role
Sole product designer on an agile multi-disciplinary team composed of a brand designer, a strategist, a marketer, a project manager, a product owner and a developer.
Challenge
StudentWiki had an outdated branding and user experience, yet at the same time struggled with ranking organically. The investigation in the current application and its the competitors, revealed some critical issues - both technical and user experience related.
One of the biggest issues tackled in this project was designing an information architecture that allowed search engines to index the wiki.
The comprehensive content was already there, yet all of it was hidden behind a login wall.
Solution
The solution I proposed, even though simple, came from the simple knowledge of Structured Data. Google offers support for subscription and paywalled content.
The design has then been built to support these types of content that benefits the business model, the marketing, and most importantly the users: they get to experience the app without having to log in.
Discover
Competitor Research
There are a number of different parties on the online market for student summaries, yet none of them acts as a wiki.
Current App Review
The functionality is the same as with Wikipedia. Someone adjusts something, this is checked and then the file is better / more complete.
Define
Persona
Understanding the target audience is crucial in every project. For example, the apps the users frequent will provide inspiration for the type of interactions they are used to.
Both the goals and the frustrations act as the north-star for my design process, always keeping me looking in the right direction. They are the holistic goals of the product design.
The persona has been defined by running a “Reasons to believe, reasons to leave” workshop, in which five users were taken through multiple scenarios, and asked to express their thoughts.
At the same time, we used quantitative data to validate the qualitative data and to get an understanding of the bigger picture.
User stories
Inspired by the way developers apply user stories to make a project actionable, I developed a system in which a product designer can expand on the persona’s goals and frustrations, generating a list of stories.
The list then gets reviewed by the client and five users, where everybody adds, removes, and/or prioritises the user stories, individually.
The priority of each story is defined based on the average Client Priority and User Priority.
As a final step, the product design team runs a “how might we” workshop in which they add Possible Functionalities that would satisfy said user stories.
This method creates a concrete and actionable list for the product designer.
Develop
Lo-fi Prototyping
During low fidelity prototyping, we went through several different design concepts that ultimately did not satisfy the user needs.
One such example is a navigation flow that we prototyped, which was laborious for a first-time user, making the experience feel sluggish.
Adopting a parallel navigation pattern, as opposed to serial navigation pattern, reduced the interactions required to switch the university by 60%.
Deliver
Hi-fi Prototyping
All the learnings from the low fidelity testing have been taken and refined in the high fidelity stage.
One highlight of this stage is the onboarding, which introduces the new users to the “Contribute” feature and the gamification features.
These features were chosen as spotlight, due to the user story validation, which uncovered a discrepancy in the “Client Priority” and “User Priority” when it came to contribution-related stories.
The users were less willing to contribute and had a stronger preference for being rewarded for their contribution than anticipated.
Check it out:
