WEDANCE | Designing a profitable non-profit
WeDance is an app which offers its services as a tool for every stage of the organisation and attendance of dance events. It provides a platform of communication between dance organisers and attendees, It is currently most popular in Germany but is available internationally.
Project Showcase
ROLE
Understanding the Goals
I worked as part of a team of UX/UI designers, working closely with the WeDance development team and the founders of the company.
iOS / Android developers
UX/UI Designers
Stakeholders
OVERVIEW
I worked on a new mobile product throughout its development period.
When I joined the team, the website had just over 1400 users and was beginning the process of design. At the time, WeDance was primarily used in Munich and Berlin as a website, having been founded and marketed there. My work was divided between the Visual Design aspects and the User Experience of the application.
Because of the breadth of design and technical requirements, my major responsibility became the design of the Premium accounts feature. The development and implementation of this feature was the method WeDance intended to create revenue.
I worked with the developers and business decision-makers to ensure that design decisions were feasible, while also meeting the essential requirements. I went on to build several interactive prototypes with each new Design Sprint and later presented the findings to the team of developers and stakeholders.
The three major goals the stakeholder wanted the team of UX designers to achieve were:
1 - That WeDance be redesigned while it was redeveloped as an app
2 – To showcase WeDance's brand and products to a wider customer base
3 – To design and test ways that WeDance could start making a profit
Problems
While WeDance was already widely used among the dance community, its growth was minimal and frequent use by its current users was rare. Although stakeholders intended WeDance to grow among dance communities outside Munich and Berlin, the app also experienced high numbers of users who created an account and then never returned.
Design Sprint
The UX team decided to use Design Sprints (as described by Jake Knapp) to quickly trial a landing page that would introduce subscription accounts. Each sprint aimed to efficiently move from inception to testing a working prototype within five days of intensive work.
With subscription accounts, what was essential for me was knowing exactly how WeDance operated and offered its services and how it could monetise its features while remaining effective to users of a free, ‘Basic’ version.
TEAM
Interviewing the Experts
Interviewing the stakeholders themselves was one of the first steps. It was essential to understanding how things currently worked and could work, as well as using the opportunity to ask about their own customer research. I developed HMWs from this, and clarified metrics and risks. These interviews were recorded and shared with my team.
On the back of this, during each Design Sprint, I would create new User Journey Maps and amend them with each new Sprint.
User Interviews
I was able to create more personae as I conducted further interviews. Event organisers could be occasional or regular hosts. A majority were individuals who did not expect a profit from their events.
No event organiser that I interviewed, who operated as an individual, had hosted more that three events a month and none did so regularly.
It became apparent that out of the prospective customers who were event organisers, the most likely users to sign up for the more expensive accounts would be dance schools, who operated with a budget.
All expressed frustration at the time it took to promote their events on the various channels of social media, the difficulty of booking artists through social media, and the organizational headache of ticketing the events. These pain-points for the individual event organiser suggest a reason why event organisers do not set up dance events to make money.
Solutions
I conducted user interviews and user tests every week.
The user interviews were to build up my collection of personae, and the user tests to get criticism of the design itself.
After the first prototype was tested, I was able to draw conclusions. I gave a series of tasks to the interviewee, observing as they attempted to complete them, and followed that by asking them questions about their experience.
The recurring criticisms broadly fell into the following categories: comprehension and explanation, what was actually offered, and distrust.
Users were not instantly aware of the benefits of what was on offer and some remained confused on certain points after careful reading. The features had to be clear and quickly understood.
When they were able to confirm the exact nature of what was on offer, some were speculative of the worth of what was on offer. This was an important aspect I realised had to be emphasised - not just to offer the services but to explain how they would help the user.
Finally, users expressed a certain suspicion over engaging in financial transactions with a fledgling app. Trust and reassurance had to be a major feature of the design.
I rewrote the copy until I was satisfied that what was offered was very clear, and each benefit illustrated visually with examples and screenshots.
As there was no data yet to statistically show the benefits of the features, I instead concentrated on explaining why they would be helpful. eg. 5000 promo emails were much more likely to be read and have results that any sort of post on social media which usually got lost; WeDance automatically taking over the social media promotion with its own templates would greatly save time; or explaining that if the benefits caused just three extra attendees it would pay for itself.
Beyond the design of the app, I devised the best way to market among dance schools was through the channels they promoted themselves, as that was where they spent so much time. Telegram and Whatsapp groups, Instagram, Facebook were consequentially the main platforms for advertising, I therefore suggested content such as videos of the events themselves in which attendees and organisers credited WeDance be created.
This would also help reassure users who were distrustful, with updated video testimonials from current users embeded in the landing page. I also submitted the company to review with Trustpilot.
Other simpler UI improvements were a smaller carousel with more information, photos in a more up-to-date style and a shorter, more efficient page.
Feedback from Participants
Completing the Design Sprints
During each of my Sprints, I would produce sketches, crazy 8s, create lightening demos and storyboards and then develop a hypothesis before moving on to wireframes and prototyping.
User testing followed; I concentrated on testing event organisers primarily, as user research suggested this was the market most likely to use the offered features.
Following the cycle of Sprints and review sessions, I refined my designs to both incorporate the feedback given and have up to date design files available to the developer team.
Example of A/B Testing
The major advantage of a Design Sprint is also its main weakness, while the designer may be bound by an intensive schedule, the test users are not, and finding and scheduling users would occasionally derail our careful plans! Happily, by the third sprint, enough users had volunteered and been scheduled in to future Sprints this problem faded away.
On the left is a still of my prototype from our second design sprint - while geared at conveying the prices and options and conveniently as possible, the way the information was written and presented and the lack of explanatory illustration was the most frequent point of criticism.
Visual Design
Throughout our design process, I also worked consistently on Figma, helping my team build up and customise our components from Tailwind as we worked on each page. We used the Atomic Theory of design as our organising method, which I found very useful when collaborating with a large team with a variety of different responsibilities and schedules.
Below you can see the first option as a hi-fi user flow. User testing showed that the most practical way to introduce paid accounts to organisers was just as the organiser was beginning his event on WeDance. I also found that all users would have been willing to test the Premium features with a free trial, which is we subsequently offered.
After entering the details of his event, he would be offered at the bottom of the Post an Event page, the option to access the features of Premium to promote his event (almost all features of the premium accounts were promotional, which meant the organiser would not have to change the details of his event). If he signed up he would be taken to payment in four further actions which would have also provided him the the information on the benefits, logged him into his account, accepted his payment method and details and confirmed his payment. He would then be taken back to the Create Event page filled in with his details but with extra options of a calendar and flyer creation.
After designing the above, I then created another user flow and redesigned the Event Creation Page. My reasoning was that filling in the Event Creation Page and then being taken to another long page of information, the Landing Page, might prove a pain point. As we had already tested the above, I decided to test both user flows as A/B testing.
The Event Page I separated into three sections, at each point there would be a CTA to the Landing Page. If the user wished to continue with the free service however, he would click the ’Continue with Free’ button and be able to scroll down through the page. This process was repeated twice. If the User chose to sign on with Premium, after completing payment he would be taken to the improved Event Creation Page, with no features greyed out. This was the Page which Users preferred and which we decided to finalise.
Problems
Reflections
By the end of our fourth design sprint, we had a prototype which had been honed and tested thoroughly and I was quite proud of the result. The KPI is to sign up 5000 new users and 300 paid users by the end of the year. I found the project interesting and enormously educational, because it required the development of an app from the bare bones to an alpha version. It progressed in an interesting way, working from the website as a hi-fi wireframe, but also innovating with UX to produce additional features, not just for design but whole strategies of marketing and promotion.