validation – My musings

07 how good is our understanding

validate hypothesis

are we solving the problem the right way

One of the crucial steps in the development process is to constantly validate our hypothesis and assumptions. At this stage we probably have a good idea about the major pain points the users are facing but we want to test our potential solutions with them and get feedback.

01 why is validation important

Here is the thing: we always think we ‘have understood’ the user goal and pain point, we think we have a ‘hypothesis’ that will solve the problem and the solution we are building would be ‘liked’ by the users and would solve their problem.

Unfortunately this is mostly not true.

It is important that we validate our understanding of the problem, hypothesis and gather feedback on the solution we have. This is not a one time activity. This is going to happen through out the product development right from the beginning until … forever. It is a repetitive cycle of DO-TEST-LEARN cycle.

02 how we validate

First and foremost, the earlier we are in the development cycle the cheapest you want to be with the effort you wanna put in to build a prototype.

Who can I start getting feedback from?

Look around, there are so many people to help. Just ask for it and you will be surprised to get so many enthusiastic responses when we pitch it the right way.
In my experience, when we build the first prototypes we went around within the team first. The team is vested, but we were critical and no $$$ spent 🙂
Often I have found some stakeholders who are not working on the project directly are easier to reach and get feedback as well. But we probably just wanna select some who kind of match the personas if possible. Again these colleagues were more than happy with a generous thank you from the heart.
Then some willing volunteers within the organisation outside the team. People within your organisation will be more than willing to spend 30 mins to give feedback. A coffee won’t harm.
Then reach out to your target users. Remember sometimes your target users may not be easy to get, sometimes you need to pay a 3rd party to organise them or quite frequently your users might be just busy. So we may have limited access to them.

03 what kind of prototypes

Cheapest options first.

Hand drawn sketches on plain paper and stick them on the wall. Then as a team walk through them. It is impossible to guess the power of this collective exercise. The discussions that happen and because they are sketches, extremely easy to modify.
Personally I haven’t used paper prototypes a lot but have used tools like marvelapp, balsamiq and at times even MS Powerpoint to create basic mockups and test the idea.
As we get more confidence and feedback keep building the prototype and adding a bit more detail but avoiding getting to a point where we have started to build detailed UX/UI too early.

At this stage we just want to check if what we are trying to build resonates with the users and make sense.