Collective UX — uniting voices, a retrospective

For our most recent user experience design project, we worked in a team of four. This was the most politics heavy two weeks of my life — ever.


The League of Women Voters, lacks digital engagement with it’s constituents, and as a result is unable to track their interests on policy areas.

10 things I learnt:

  1. When you think design, you think style, you think functionality. Definitely not something like numbers and graphs, and analytics. But when you have an ambiguous design problem, research and statistics are so important in defining the solution, and the direction. For our project, we had thought the problem was people hasn’t heard about the League and didn’t know they existed, but stats showed, it was more to do with the fact they didn’t know what they do today. That meant we shouldn’t try to come up with a solution to market the name, but a solution that clearly communicates what the League does.
This shows people know about the League, but 56% of the people go to their website to immediately leave, because it’s not easy at a glance to understand what the League does.

2. Initially when we got the project brief, we were all pretty confused as to what we need to do. But as soon as I mentioned Humans of New York, we need some sort storytelling like that, everyone’s direction was aligned. This really goes to show that when you have a great product, people associate with it, it is no longer just a functional product. It can become an inspiration! Something to think about for all future designs!

3. There is no shame in stealing like a designer! For our app, we used inspirations from Humans of New York, we took the autoplay feature from Instagram, the continuous scrolling news feed from Facebook, the secondary topic navigation from Twitter. When something already works, just use it, and spend time solving problems for things that don’t.

4. Many times through out the project, we got excited we came up with a product solution. Only to be totally slammed down when user testing. The product is good to use, but they keep asking, why should I start using it, and keep using it? We realise this was such an important question to keep asking ourselves. It’s not only important to have a good product, but what’s the bait for people to want to spend the cash or download and engage? Like if you have a good restaurant, if customers are not hungry, why do they want to go there? Our app went from single directional input to multi-directional. We opened up the commenting, feedback and share functionalities in the app, because we realise people don’t just want to share. They want to share, know they have been heard, and get feedback on it.

5. In a team environment, it’s more important to get things done, than worry about if this is what you want to do. Everyone all have something they want to do and/or good at. When those don’t align, it’s important to get a balance of both, so project gets done on time whilst remaining happy. A few of us went in the project wanting to do more design tasks, me included, but I soon realised in order to get the project done in two weeks, I need to do more analytics, because that’s my background, and I could get it done faster. How do you find a good balance? Iterate.

6. When in a team, time keeping is even more important. We had a lot of discussions to get the project going, but for every task we go into a discussion about, a timer was set. This ensured we talk only about the problem at hand, and always resulted in an outcome. We weren’t just discussing for discussion sake. Things got done, because we knew we had to make a decision when the alarm goes off.

Time crunch discussion.

7. When user testing, define, define, define! It’s so important to be specific to the dot when you want to do testing, both in the scenario and task. If you are not specific enough, users go off on a tangent, and what you wanted to test doesn’t get done. Yes, it’s important to note what the user might want to do, but that’s more a matter of asking their opinion at the end rather than in the beginning. Because we are testing a low fidelity prototype, if we weren’t specific, the user might end up tapping a function that hasn’t been fully built out yet, creating a bad user experience. Initially we just told our users, they were frustrated and they wanted to use the app, but soon realise we needed to tell them, you are frustrated, use this app to share your story. It wasn’t working letting them discover they could share their story on their own, as sometimes they didn’t want to share their frustration, so we couldn’t test that functionality!

Paper prototypes.

8. Most of the time I think if I get a product, the more functionality it has, the better. Not the case with mobile apps. Because there are limited actions available on mobile, a design need to be simple to be effective. For a simple product, simple functionality goes hand in hand. Initially for our app, we had four functionality designed out, we thought we were giving users bang for their buck. Not quite the case — during user testing, people had no idea where to go for what, it just wasn’t intuitive. So we went back to defining what are must haves for our product, re-defined the MVP, and cut the function down to one main function, plus a sub, second level function.

Our iterations from left to right.

9. Through out the project, we had many iterations, and many direction changes. Half way down the line, we had a session where everyone had three minutes each to articulate what the problem and solution is. We identified there were differing perspectives due to the fast pace of it all. Because of that, we had to spend more time discussing it, and realigning. If we did this more often, it would be great to make sure we are working as an effective team, all trying to get the same product out. It would’ve been bad if at the end, no body recognise the final output.

10. UX itself it quite a broad topic, and at times can be really confusing as to what goes under the umbrella. In our project, it was a fine line between marketing, branding, and product design. We realise UX is all encompassing — user experience is the whole journey — from what people perceive about your brand, what people feel when they see your marketing, to what people feel when they use the product, and let’s not forget, what people feel when they are done with your product! There is no need to keep asking if this task is UX, because it is.


We made a mobile app that allows constituents to share their voices on political issues, engage with other constituents with similar interests, at the same time allow the league to track interest and concerns in the topic. See our prototype here.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.