At Made By Munsters we work with companies of all sizes. Some are brand-new start-ups. Others are well-established, long-standing businesses. Yet, we treat all companies the same when hired to design and or develop their products.
Our process always starts with an explanation of our design and development goal.
That goal: Build for day one. Don’t focus on what’s to come a year from now or even three months from now. Focus on your first release.
Our team looks at the immediate needs and problems our client may be facing and then as a team we define a solution that best fits the first release needs.
Defining Day One
What do we mean by day one?
At Made By Munsters, we are not big fans of MVPs or minimal viable products. To us, those types of products don’t solve the problems that clients hired us to solve. They scratch the surface and allow a company to test an idea, but they don’t solve the problem.
Instead, we build proven solutions for the first release.
These solutions address the issues, we as a team, have identified as problems early on during the product’s inception phase.
How do we know a solution will work or consider a solution a proven method? We do this through early-phase testing. By getting a product in front of users we can test theories, tweak features and release a solution that meets our client’s needs right out the gate.
This is why we refer to our products as day-one releases rather than MVPs.
Developing A Day One Release
In order to develop a full-scale solution for day one, there are several key steps that must be completed. At Made By Munsters, we found that following this process has led to the best outcomes.
Those steps:
- Develop a working thesis or hypothesis that the client and your team agree on.
- Don’t solve problems that don’t exist.
- Test early and often.
Develop A Thesis / Hypothesis
There was once a great philosopher who said:
“To truly solve a problem, one must fully understand the problem they are solving.”
Well, maybe someone didn’t say those exact words. But I am sure someone made similar remarks at some point in history.
The goal of this step is: Understand what the product will solve. Research platforms that solve similar problems. Then, establish and determine how this particular product will differentiate itself from others in the marketplace.
Once the client and your team are on the same page, write down this goal. Don’t lose track of it. Pin it up to a wall. Make it your desktop background. Do whatever you need to do to stay focused on it.
This is the most crucial step in the entire process. As products grow and scopes change, this thesis should remain constant. If it does not, you will need to re-evaluate what you’re building.
To build a truly successful day-one product, it’s important to stay true to your original assumption. At least in some shape or form.
Solve Problems, Don’t Create Them
We have said this before on our blog — Crafting Our UX Process — but it’s important to solve problems that exist. Don’t create problems or find solutions for issues that have not been voiced.
This is easier said than done. But if you have done your homework, interviewed your users and have a clear thesis statement, you should be able to avoid these unnecessary features.
When you solve problems you anticipate, rather than find solutions for what’s right in front of you, you will find you fail to test and complete core functionality.
We’ve made this mistake many times. I am sure all design and development studios have at some point in their history.
As clients ask for more and more features without adjusting timelines, you rush and haphazardly deploy features. This must be avoided.
It’s best to discuss and analyze what features make sense and what can wait. We ask for data and or case studies to help us understand why these new features might be needed for day one.
If that type of information is unavailable, then wait for it. More often than not, you will create a solution for a problem users did not need to be solved.
Testing 1, 2, 3
Lastly, test early and often.
We use paper prototypes and interactive mockups to test our ideas. This allows us to rapidly iterate and tweak solutions before the intended release date.
Testing doesn’t have to be formal. Use the resources you have around you. Ask a friend who has no experience or knowledge of the application to complete simple tasks. Watch how they progress from one view to the next. Ask simple questions. Don’t instruct them how to complete a task, merely guide them.
Taking 30 minutes to tweak a design while it is still under development can save you hours of time after it has been released.
Next time you meet with a client and begin the process of starting a new product, I challenge you and your team to think about day one.
If you are interested in learning more about our design process and how we build our clients’ products take a look at this post.