Sany
Discovery, Visual Design, and Prototyping Case Study
Duration: Mid 2019 – Early 2020
Platforms: Android, iOS
Team/Role: UX Designer on an interdisciplinary team of 5
Website: Coming soon
iLab Overview
This is a quick introduction to the iLab program to provide context for the project.
My senior capstone project took place during a six month exchange program in Sankt Pölten, Austria where I participated in the award winning iLab; an interdisciplinary, international program hosted by the St. Pölten Universit of Applied Sciences.
Each year, twenty four students from around the world are accepted into the program, assigned into teams of two, and tasked with finding solutions to different societal and global issues. Periodically, team’s are cut. Members of teams that are cut are then added into the teams who survived.
In the end, the four most promising projects are seen through to the completion of the iLab and are developed into actual products.
Project Overview
Problem
From the beginning of the iLab, I was assigned to the challenge “How to use digitalization to promote gender equality.” In order to address the bigger issue of gender equality, we chose to hone in on a root problem that leads to increased gender inequality, specifically in Austria.
One major challenge to gender equality in Austria is the practically nonexistent sexual health education for youth.
Earlier, in mid 2019, the Austrian government passed a law forbidding Non-Governmental Organizations (NGO’s) from being able to teach sexual health education in public schools, thus crippling sexual health education in Austria, which already had a faltering health education system.
Studies show the majority of youth in Austria have a wildly inaccurate understanding of their own bodies and an even greater flawed comprehension of the opposite gender. This poor education prevents young girls from feeling autonomous and empowered to handle menstruation and other biological changes. Poor sexual health education decreases understanding and respect between genders and leads to increased sexual violence.
Solution
Of the 9 teams that started the iLab, my teams project remained uncut through the entirety of the program. To combat the problem above, we created Sany, a platform connecting youth with questions to experts with answers.
Sany allows youth to anonymously ask questions which are then answers by experts in the appropriate field.
Our app creates a sustainable way to help youth find accurate answers to important questions while also providing NGO’s the opportunity to connect with and teach youth whom they otherwise have very few ways to reaching.
Challenges
Building a user base
It would be paramount that our solution be a product youth would actually use. There are several companies who are attempting to bridge the gap between youth and the poor education system, but none do it remotely well enough to have much impact.
Another crucial part of Sany’s success was based upon our ability to market to experts in a way that would motivate them to use our product to help youth. Without active involvement of expert users, Sany couldn’t exist. On the same token, the experts would have nothing to do on the app without youth asking questions, so we also needed to build a critical mass of youth users.
Development
Being that we were an interdisciplinary team of a social worker, engineer, animator, media manager, and myself, an interaction designer, we had very limited skills and abilities when it comes to app development. Myself and one other had experience in basic web development, but since I was focusing on the design of the app, other team members had to step in to assist with the programming.
Results
Unfortunately, though we have a good idea of the effect it could have, we don’t have any authentic results from the app being used in the wild. Our team conducted hours worth of interviews and tests with dozens of youth and experts. These tests show extremely promising results and we believe the trajectory of the app puts it in a very good place to fulfill real needs of people here in Austria.
Discovery
Other members joined later as their projects were cut, but the discovery process was completed by myself and one other teammate who comprised the original team assigned to this challenge.
Observations and Analysis
As was mentioned earlier, the Austrian government passed a law forbidding Non-Governmental Organizations (NGO’s) from being able to teach sexual health education in schools. The consequence of this law was an undertrained staff of teachers being forced to teach sexual health courses that they were neither comfortable or qualified to teach. Our desk research showed the vast majority of youth have an aversion to discussing sexual health topics with parents and teachers which means youth are often turning to the internet — a bottomless pit of scattered, opinionated, and inaccurate information — for answers.
We held qualitative interviews with 8 youth (ages 15–20) to learn more about their perceptions of sexual health education and to determine what sources they would trust for this type of information.
We found that many of the youth we interviewed typically avoided social media and youtube when seeking credible information and gravitated most heavily towards reading brief, question-based articles from experts.
Ideation
At this point, it was time for the Gate 1 presentations which would determined if our project moved on. After presenting our research to the panel of judges, our team was voted to continue and a new teammate was added to our team.
As the teams only designer, I led us through the design process from this point forward.
Value Proposition
We collaborated as a team to come up with a value proposition for our product. We began by asking questions such as:
- What are our users pains?
- What do they hope to gain?
- What jobs are they trying to accomplish?
By thinking of these questions, we were able think specifically about exactly what functionality our app would need.
Priority Charts
Having a better idea of the functionality needed for the app, we created a priority chart to learn how often different features would be used by our users, thus helping define the hierarchy of our app.
I organized each functionality we identified in our Value Proposition into features and then plotted those features on the charts below. Based on our previous interviews with our users, I determined how frequently each feature would be used and by how many of our users.
Distilled down, we essentially learned that for Learners:
And for Experts:
Design
At this point, we again, presented our findings and a rough prototype of our app in the Gate 2 meeting. Again, the panel of judges found our app exciting and compelling and our team was moved through to be allowed to actually build the product.
All app designs were done by myself.
Navigation Map
With the knowledge gained from the priority charts, I created this navigation map to begin creating the structure for the apps flow. I focused on making high priority features readily accessible and intuitively buried less used features in the layers beneath.
Onboarding
Principles
Clearly emphasized anonymity and credibility
Features
In order to emphasize anonymity in the app, I designed a thorough onboarding experience that humanizes users and helps them feel that the app is respectful of their privacy and will cater to the experience they want to have.
Sketching
When designing the onboarding experience, I wanted to focus on how the copy guided the experience and how tone of voice could set the stage for the rest of the app. My initial sketches, therefore, were dialog chains.
Prototyping
By sketching the dialog, I quickly found a tone of voice that created the feelings of respect, privacy, and credibility that I was looking for. In very few rounds of iteration and testing, I landed on a design that tested well and prepared users for their experience with the rest of the app.
In the video above, you’ll notice each screen has a fair amount of dialog. One concern I initially had was about if there was too much dialog. Would users even read it? If they didn’t read the dialog, would they still understand the purpose of the app and what it offers them?
Testing and Results
To ensure the onboarding process made sense, primed users for the app, and started users off with a delightful experience, a team member and I met with local youth to test the app. In user testing, half of those tested read the dialog on each screen. This half of the test group understood and appreciated the intentionality of the text and were excited by the anonymity Sany could provide while still allowing access to tailored answers. To my excitement, the half of the test group who ignored the dialog were still able to navigate the onboarding process well and accurately perceived what their experience with the app would be like.
Home Page
Principles
Speed to access applicable content
Continue to reinforce credibility
Features
To make finding the desired content as easy as possible, I put the most pertinent information on our landing screen. There are three types of content cards in the app, so I made a home page that features each of these three cards to help introduce them to our users. This way, users can begin familiarizing themselves with the way they’ll see content displayed when they begin searching for their own questions.
Iterations
The layout of the landing screen has remained very similar to early iterations which I attribute, in part, to how well we understood our users and their needs. The home page features mostly remained the same, with some adjustments to the bottom app bars navigation icons.
Prototyping, Testing, and Results
After one round of early testing, it became clear that users assumed they would find their likes and bookmarked answers on their profile page, rather than on the home screen, so I moved navigation to those pages from the bottom app bar into the user profile page. This was more intuitive and resulted in optimal path outcomes in user testing.
Expert Profiles
Principles
Establish individual credibility
Give quick access to experts content
Features
We realized early on that our users cared slightly more about the opinion of the crowd than the actual credentials an individual holds. Because of this, the most predominant information on the experts profile is their name and image, which humanize them and make them more trustworthy; their profession, which the experts and NGO’s felt was important to display; and their overall rating based on the average of their individual answers ratings. For our users who were still interested in seeing more credentials, we created an about tab where experts could expound on their qualifications and background as well as link to their practice or organizations website.
Iterations
I tried several different versions of the expert profile with minor adjustments to make the tabs more noticeable. I also adjusted the layout to create more whitespace.
Prototyping, Testing, and Results
I found there wasn’t any noticeable difference in results between the option with more white space and the more condensed version. Since both options tested about the same, I chose to go with the condensed version because it showed more content initially.
Below is the prototype of the expert profile, but as an expert user rather than a learner.
Question and Answer Editor
Principles
Simplicity
Reinforce anonymity
Features and Iterations
For our youth users, the original flow I created was a very simple editor with some rich text editing and that was it. There was no message at the beginning or tagging options at the end. I realized there were a couple flaws in this overly simplistic approach. 1) Users entered the question editor and didn’t really have much context about what would happen after they posted their question. Who could see it? Would their account information be displayed? 2) Users couldn’t add tags to their questions, which would make it difficult for us to develop a search algorithm that was consistently connecting experts to the right questions and connecting youth to the right answers. 3) There really was no need for youth users to have rich text editing in their questions. For consistency, it would be best for all questions to be formatted the same way and to have a character count to limit their length, again, reinforcing the idea of keeping questions from becoming whole stories.
To improve upon each of those areas of concern, I 1) added a mini onboarding modal to remind users that their questions are anonymous, 2) added a flow on the end to confirm users are ready to submit and are able to add up to 5 tags, and 3) removed the rich text editing for youth users and replaced it with a character counter similar to that of the one used in Twitter.
Prototyping, Testing, and Results
The question editor flow was intuitive and made sense to the youth we tested it on. However, as I was testing other parts of the app, namely the Answer page:
Users had a hard time reading through all of this content without any headings, subheadings, bold text, etc. So to combat this, I reinstated rich text editing similar to that of Mediums rich text editing, but only for experts answering questions. This way, we keep simplicity and unity for questions, but allow experts to clearly answer questions in a digestible way.
Branding
At Sany, we had the belief that our brand was the promise we were making to our users. If we branded our product well, we knew that would help users have a clear expectation of what to expect from every aspect of our product. We wanted to ensure that at every level of our product — whether it was marketing, design, or development — we were consistent in the promise we provided to our users. To accomplish this, I, in collaboration with the team, created a simple Branding System to act as a guideline for everything we worked on.
Conclusion
What was the end result
Though we haven’t quite reached the end of the iLab, the end is near enough to be able to look back and evaluate this experience.
What we’ve got right now is the beginnings of a Flutter app. Its been fully designed. We’ve coordinated with several NGO’s in Austria who are excited about the product and have committed to dedicate resources, namely their experts, towards helping this product grow into a reality. They’ve also committed to advertise for us in their workshops they host throughout Austria.
At this point, its just down to finishing the development of the app.
How did the change effect user’s
Unfortunately, though we have a good idea of the effect it could have, we don’t have any authentic results from the app being used in the wild. Our team conducted hours worth of interviews with dozens of youth and experts and we believe the trajectory of the app puts it in a very good place to fulfill real needs of people here in Austria.
What did I learn through this process
I learned about the importance research. Before ever even attempting to create an app, we spent 6 weeks understanding exactly what the problem was, who it was affecting, and how it was affecting them. The more we understood the problem, the more the solution became clear.
What would I do differently?
Looking back at this experience, there are two regrets I have.
- I wish I would’ve invested more time into testing the prototype with experts. We included experts at every stage of the design process and were constantly getting feedback from dozens of experts, but I’m less confident about how experts will actually react to using the app because we didn’t test experts as much.
- I wish I would’ve learned Flutter sooner. I’m currently learning Flutter and Firebase to try to help with the development of the app, but we likely won’t very much time to QA it. If I could’ve started programing a month earlier, it could’ve given us a better lead before our final presentations.
One of my favorite pastimes is connecting with other humans! Please reach out and connect with me via LinkedIn or email.
Check out more of my work and don’t hesitate to provide feedback.
Thanks,
— Jackson
