Proof of Concept
This week we spoke about the proof of concept. Before this though, we had a talk about the Co-Founders programme at Catalyst.
Daniel started off by telling us to ask ourselves two questions about our product ideas:
- Does it exist?
- Does it need to exist?
He then went on to teach us about conducting a SWOT analysis.
We also learnt about pitching our ideas to the target audience first. This way, we can confirm assumptions and validate the idea so that we know if it’ll be worth going forward with or not.
Daniel then went on to speak about doing some user research to further understand who we’d be making the product for, and how to tailor it to them properly.
This included the type of data we’d be collecting through our research. The best way to go is to compile both qualitative and quantitative data.
- Unstructured with open ended questions. This gives us a chance to receive richer, more detailed data
- Subjective. This would include the opinions of the user, and their own points of view
- Insights and theories
- Structured using closed-ended survey questions. This provides Measurable data and statistics that can be very valuable
- Objective and factual
- Allows for theory testing
Basic Steps for User-Centric Products & Research:
- Define primary user groups
- Pick techniques for involving users
- Conduct research
- Validate definitions and analyse research
- Generate user requirements
There are all different types of bias that can occur with user-testing, these include:
- Cognitive bias
- Group think
- Selection bias
- Cluster illusions
What to do with Results
With the results you get from user testing, you can then create user personas to better understand your users’ needs, wants, and frustrations. We can also create an empathy map. This can help UX designers understand our users on a deeper level – and allows us to empathise with them. This means we can create a product for the user, and not just because we think it’s a good idea, or would be a fun project.
Users are people too. They will be easily led, so we must avoid leading questions.
For next week, Daniel wants us to conduct a SWOT analysis of our product idea. This will allow us to properly think about whether or not our product is worth making.
After this week’s lecture, I am looking forward to conducting my SWOT analysis, and then some user research to aid my understanding of the product, and how (or if) it will actually be useful to people.