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 also available internationally.
I worked as part of a team of UX/UI designers, working closely with the WeDance development team and the founders of the company.
ROLE
TEAM
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.
Understanding the Goals
The three major goals the stakeholder wanted the team of UX designers to achieve were:
1 - That WeDance be redeveloped as an app and redesigned in such as a way that it could monetise its services through subscription accounts.
2 – To showcase WeDance's brand and value to a wider customer base
3 – To design and test tiered benefits that WeDance could offer.
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 rarely engaged.
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.
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.
The stakeholders explained the gap in the market they sought to fill - a platform which explicitly focused on the promotion of events and the easy facilitation of communication between organiser, attendee and artist.
I developed HMWs from this, and clarified metrics and risks. These interviews were recorded and shared with my team.
User Interviews
I was able to create more personae as I conducted user interviews. I found event organisers could be either 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.
UX Methods
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.
Feedback
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.
What exactly to offer? - Premium Account Features
The other essential use of the user research was to gauge how appealing the proposed benefits of the premium account were to users and whether there were any possible further features which could be offered.
Two features we devised from personae, based on the frustrations of users were:
The instant booking of artists
Guaranteed regular promotion to 2000 newsletter subscribers
The set-up of Editor Accounts, which could organise other accounts in the same group to create events - a feature designed for dance schools.
With the introduction of new features, the parameters of a basic account had to be established as well:
Users of the Basic account would only be promoted in the newsletter once, during the week of the event.
Also, most crucially, Basic account users would be limited to organizing only one event a week.
This was a result of researching user behaviour and finding that free promotion to the WeDance community and across platforms was the most highly valued feature as it currently stood.
It also found numerous examples of edge cases, where a small number of organisers would promote multiple events during the same week and consequently drown out other events in WeDance's timeline.
I therefore proposed and designed a limit to the number of events one could make a week - and, anticipating that users may begin planning events many weeks in advance to take advantage of the once a week promotion structure, also a limit to the time ahead a Basic user could create an event - one week. Premium users could plan an unlimited time ahead and promote their events on three separate occasions.
Solutions
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. 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.
Wireframing and Prototypes
Below you can see an early hi-fi wire frame, a result of a few design sprints. User flows showed that the quickest, 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 what we used for this flow prototype.
The user would have the option to access the features of Premium to promote his event (almost all features of the premium accounts were for event promotion) after cliking on one of the features offered and being taken to a landing page.
If he signed up he would be taken to payment and then back to the Create Event page, still filled-in with his details, but with extra Premium features.
After user testing the above, there was an overall improvement in user comprehension and experience, but low levels of conversion continued, and so I facilitated a new approach.
We used the ‘freemium model’ of offering premium features as part of the experience of the Basic User, before eventually hiding them behind a paywall. This would enable all users to experience the benefit of the features offered.
User testing this version provided a measurably improved user experience. The user did not have to do anything, and so was not held back by distrust or fears of a bait and switch, instead reciprocity was encouraged in the user as well as comprehension and experience of the benefits of a Premium Account.
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.
Problems
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.
Reflections
By the end of our sixth 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. The conversion rate for new users was 74% within the first two weeks. 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, but also innovating with UX to produce additional features, not just for design but whole strategies of marketing and promotion.