User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Could you please any one tell me about the UX method for MINIMUM VIABLE PRODUCTS?
We can't follow the traditional UX Strategy such as user research, scenarios, prototyping, user testing etc.. for the MVP products.
Is there any better way to do the same?
I'm not sure you understand what minimum viable product is.
The minimum viable product is the minimum your users will accept/pay for.
If you were inventing mechanised transport for the first time you might be trying to build something to replace the horse and cart - your minimum viable product could be a bicycle but only if your end users are mainly interested in getting around faster than walking. If your users are only interested in transporting goods then a bicycle would not suffice as MVP - You users would reject it as it doesn't meet their needs.
To discover what your MVP should be you need some sort of insight into what your users want. That's what your research is for: understand what the user wants and what they will accept.
I partially disagree with what was said before: The MVP is a term from agile methodology - it is not the "little brother" of a finished product, it still is the product itself, just in an early stage. To pick up the metaphor Splatz used: The goal could be to build a racing car with the purpose of being very fast. The MVP here could be a bicycle. Why? Because it already transports you faster than now, even if it only has 2 wheels and no steering wheel - but it already provides "quicker than before". The goal of an MVP is to provide a minimum functionality that already provides improvement to the previous state.
Looking at it like this, the work stays exactly the same from UX perspective: You research, you create concepts, designs for the final product. The goal always has to be the final product, BUT the current sprint's MVP always has to fill all needs, also for the user perspective.
Coming back to the example: Assume a question is, if we include a steering component in the "bicycle" MVP. The UX answer to that would be: Yes, because the steering functionality is a fundamental inclusion from user perspective: If she can not steer, she does not get where she wants.
To understand what the UX perspective on an MVP is, you have to look at the completed vision, the final product. Never develop to get an MVP, always develop for the final product, but define steps in between that increase the functionality and worth of the product.
To sum it up: Nothing should change in your UX workflow, when you have to look at MVPs.
It's the only strategy that's left when you strip all the work you can do yourself. iOS/OS X, Android, Windows all have their own UI guidelines. For the web there is W3C. Find the (UI) guidelines for the frameworks and tools that you use. Also look out for other do's and don'ts by reputable people, books or sites. You probably already know where to look or otherwise search the web for it. Good luck!
I think you may be misunderstanding the point of MVP. It does not mean that you skip all of those steps.
From my blog post on the subject: http://commadot.com/mvp-deconstructed/
Hopefully, it will help. Additionally, I am a believer in Minimum Lovable Products. It is like an MVP, but with some details thrown in to make it more appealing.
The key to all of it is to release something useful and lovable without building every feature you can imagine. It's about prioritization and figuring out how things hang together in a release. UX should not be eliminated in that process.
Another way to think about minimal viable product is using an example.
Imagine you have a table of data.
Other features could be added to the table to enrich the table functionality, e.g. Search, filters, column sorting, customising the columns you want to show or hide, customising the sequence of columns using drag and drop, changing the width of the columns using drag and drop, inline editing of the data, grouping columns, exporting the data to Excel, etc.
The point here is it is you and your team who choose what the minimal viable product is.
Most definitions for MVP state that it is the minimal amount of functionality you need to have for the solution, so that if you took just one feature away it would no longer be fit for purpose.
How you choose what is in and what is out, could come from insights discovered by UX research or you can simply make team decisions about what is the minimal you need for your market.
You have to be very brutal when considering what is in and what is out, because in the example I have just used, maybe a simple table without any additional functionality could be the MVP and is all that you need.
Completely agree with @jazZRo about following guidelines, if nothing else you should be doing this.
But also consider that just because those things you don't have time to do, or resources for user research, scenarios, prototyping, user testing... doesn't mean you can't do a small part of them.
Each of these things could be a large undertaking, but they still have lightweight/bootstrap versions as well.
Can't perform user testing? Grab a friend and get them to try and use your product.
Can't do a detailed scenario? Pick one or two common situations and spend 5 mins writing down a user path on a bit of paper or discuss it with someone. You must have some scenario in mind, as the product is most likely solving a problem.
No time for prototyping? Again, pen and paper and 5 minutes sketching.
Research? Have a quick look at similar products/UIs/apps, or crawl around a few articles to get a feel for how some users might interact with it. Over time you learn some base level things about how users might behave in general situations - not enough to base a complete app on, but enough to get an MVP UX started.
Try doing the 'MVP' (I'm using this as a synonym for the smallest work necessary), for each of those tasks. It's not 'all or nothing' when it comes to prototyping, research, user testing etc, you can still scrape together some of these things to at least build a foundation for your UX MVP, and then build on it later.
As Ryan Hoover (founder of Product Hunt) puts it in his now well-known article, The Wisdom of the 20-Minute Startup: “The purpose of an MVP is to learn, to validate & invalidate assumptions.” Here the key take-away is "Assumptions" you decide to set out with, and which through the MVP you validate. Note few things:
1) In terms of UX process, note that a MVP, depending upon your context, need not be a finished product. Since you are testing an idea/assumption, you could very well do that, say in the prototyping phase. An 'invision' styled prototype could undergo some decent usability testing, and you could very well get results you might need. So its important to understand, "at what earliest point can i test", and not follow the rules blindly.
2) Focus is more on research around the product domain. So in terms of UX startegy, I will weight that heavily. Once that is in place, with your set of assumptions - then since the idea is to get the simplest (capable) product, these wireframes/scenarios are a piece of cake. So go ahead and do them, and you will see what I am trying to suggest.
3) Very important point I would like to add here - MVP is a product that users will use at the end of the day. Its for them. Do not discount aesthetics, or emotional quotient from the product, for the sake of being 'basic'. There is some buzz already about building, Minimum Lovable Products rather than just Viable ones. A good read is here: https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c
Well, Nokia started out as a paper mill in Finland & Twitter as a podcasting company called Odeo. You get the point. MVP's are not meant for being alive till eternity.
I think that UX methods are more suitable for a prototype, but if you already talk about MVP, there are common steps.
Step 1. Define the problem This is a situation when the first step can define your whole business path.
You’ve got an ingenious idea and immediately start the development. Later you recognize that the idea is great, but no one actually needs it.
To reduce the risk of failure, you should start with a problem definition. If you identify an existing problem, your solution is more likely to find many users.
Step 2. Define the target audience Trying to target all users is another mistake. It is impossible to get everyone to use your product. Therefore, it is much easier to satisfy a certain group of people.
Build your buyer persona and make it as specific as you can. Define age, profession, education level, earnings, family, hobbies, etc. The better you know your potential customer, the better you can meet his expectations.
Step 3. Specify the minimum feature set Here comes one of the most difficult parts of building an MVP.
When you initially thought about your product you probably identified dozens of unique features to charm your customers, but unfortunately, you’ll have to put all these ideas aside until you test your assumptions concerning the problem that your idea will solve for users.
It’s best to start with is the minimum set of core features which will bring value to the customer. Ideally you should include only one essential feature.
As an example: You assume, that your potential customers want to move faster. You want to build a car to solve this problem. To test your assumption you start with building a minimum viable product.
MVP: A skateboard.
Not MVP: Four separate wheels.
An MVP might help you to prove your assumption, and validate your product idea. If your target audience is interested in the skateboard, then you were right, they are in need of a vehicle which helps them move faster, and they are ready to pay for it.
If you offer the customer four wheels - this will not solve his problem. But a skateboard will.
Your MVP might be primitive, but if your idea provides a solution to an existing problem without neglecting the user experience, it will have users and the MVP will prove this assumption.
Step 4. Build MVP After defining the core features for the MVP, it’s time to build the product.
The first rule is: Forget about perfection! At this stage, your only aim is to release the product as soon as possible to test your assumptions.
The sooner you get the product into your user’s hands, the better. From their feedback you’ll understand whether they are interested in this kind of a product, or whether the development is a complete waste of time and money.
And remember, if the users like your minimum viable product with all its imperfections, the full version of the product is much more likely to charm the whole world.
Step 5. Test MVP After your minimum viable product is finished, get it into the hands of potential customers. Remember one of the first steps, the target audience definition? Find people who match your buyer persona and ask them to test your MVP.
If you did everything right (defining the problem, the target audience and the minimum features set) you’ll receive relevant feedback. This will be your clear guide as to what to do next.
You should take the customer feedback seriously.
It will show you whether your idea is worth investing in or not; It will prove that you defined the target audience correctly; It will give you a clear vision of how to develop your product further; It will reveal which features your product needs, and which features ot does not need. These are reliable facts, not just assumptions.
You may be afraid of receiving negative comments about your product, but in this business there is one thing to remember: Negative feedback is better than no feedback.
Step 6. Improve your minimum viable product After receiving reliable feedback from your first users it’s time to take advantage of this information.
So, you know what your users like and what they don’t like. Now you can improve the good features, remove the bad ones and add something new to see whether or not it will work.
Also more about prototype and MVP: https://clockwise.software/blog/how-to-make-a-prototype/
https://inventionland.com/inventing-process/prototyping/
https://clockwise.software/blog/minimum-viable-product
http://whatis.techtarget.com/definition/minimum-viable-product-MVP
Product strategy is the basis of the life cycle of your product and the basis on which the plan for all future work is based. It allows UX designers to decide which audience should focus on, as well as focus on the characteristics of the consumer and the product itself. Many companies, for example, https://mindy-support.com - decide to use machine learning. As a UX specialist, you have the right to your vision.
