Minimum Viable Designs


Collection of UX tips to ship applications that customers want to use. Useful for developers, indie hackers and founders. Avoid making basic mistakes and start with a solid foundation. Save time and focus on growth hacking. 


  • "Under resourced teams (probably the majority) have devs doing design work. This is a nice, clear set of techniques to help avoid the bigger pitfalls. And nicely illustrated!" - nijollas-wilson (through Reddit)
  • "Cool site! As a dev figuring out the UX is a pain and pretty time consuming." - paulis (through IndieHackers)
  • "This is a great resource that you're putting together! I tend to refer to these as "patterns" in the sense that Christopher Alexander used in his book on architecture, "A Pattern Language". jroutens (through IndieHackers)

This pyramid diagram was part of the successful presentation that busts common misconceptions about MVP. Highly recommended!


Build small-scale complete solutions iteratively. The diagram explains the right approach to build MVP from the UX perspective in a very simple way.

Neither producing multi-feature app, nor single feature hyper optimized for pleasurable experience would give you the constructive product-market fit feedback.

Better way is to produce the smallest core functionality with pleasurable design. And you will receive useful feedback as a result.


#1 Save visual prominence for signaling the next step

Use color contrast wisely.

Elements with high intensity color in combination with high level of occurrence hurts users' eyes. Intense backgrounds produce feelings of heaviness. This doesn't have an immediate effect on user to simply bounce off your app and jump the competition. But rather accumulates the feeling that the information are hard to scan as the contrast pulls the attention in a wrong direction. Opportunity lies in a light backgrounds that bring the actual content on the spotlight.

What you want is to highlight actions that generate new content and help to move forward towards the accomplishment of the tasks. Next step has to be a no-brainer.

Rule of thumb: Use high contrast, high saturation colors for buttons and active elements only. I mean those dedicated to dynamic data manipulation (filters, switchers and etc.). Rather than backgrounds of navigations, footers and modal windows.

In case you decided to use a dark background, at least decrease the saturation to a minimum. Use the HSL color model to fine-tune the parameters of saturation levels.


#2 Split the options based on purpose

Navigation is basically a crossroad for the most useful screens. Its structuring could be a challenge, when dealing with tens of potential links to be categorized. One helpful trick from the beginning of the structuring process is to split all the possible links into two buckets. Namely Categories and Utilities navigations.

1. CATEGORIES (Content) Navigations
Content representation: Presents links to screens dealing with primary content of the application.

UI representation: Typically located on the left side of the screen. All items of the navigation are always visible (considering desktop viewport, might be hidden on mobile).

2. UTILITIES Navigations‍
Content representation: Ancillary elements covering secondary actions, accessed less frequently by the user.
Examples include authentication, management of settings, account related details, personal details, sorting and filtering mechanisms, data manipulation etc. Navigation links and information pertaining to them are not part of the website content hierarchy.

UI representation: Usually placed on the right side, close to the corners and edges of containers. As they serve secondary functions, they are often hidden under the dropdowns or popups. Often accompanied by icons to increase speed with which users spot the expected options. For instance icon of a bin with “remove", plus icon and “add”link, cog icon and link to "preferences" etc.

Mixing navigations is risky. This widespread interaction pattern teaches users to expect utilities to be found on particular locations on the screen. Placing them to expected locations improve productivity within the app.


#3 Place datatable controls to expected positions

Tables are the core element of the any web application. Amount of information they present will always grow with time. Hence controls helping user to find a specific piece of information or a relationship pattern, are essential. Over time software creators used uniform positioning for these controls to leverage a habits users built over the last decade of using software. Misalignment of these controls becomes an issue when we add new features and they become hard to find because of visually cluttered interface.

These are the 3 types of active elements altering the values presented in the table from the perspective of positioning.

1. Updating and transferring data (Recommended position: Top table edge - left or right corner)
Examples: Adding new table items, Bulk updating, Share, Multiselect, Download, Print, Multiaction dropdown

2. Reorganizing data (Recommended position: Top left table corner)
Examples: Filtering through Dropdowns, Datepicker, Sorting mechanisms, Search bar

3. Batch preview options (Recommended position: Bottom table edge)
Examples: Pagination, Lazy loading button, Density rate (quantity per page), List vs. Cards preview

Don't follow this positioning tips rigidly. You might find a better placement based on user testing. This is just a good-to-start-with guide.


#4 Navigate through unfamiliar field with wizard

This common application-design pattern exists to increase input accuracy by giving more control to computer side. Especially when user don’t have enough domain expertise. This simply means being unfamiliar with any complicated process within your app. Wizard can be also perceived as a mini-application that takes the user through a sequence of forms.

Without the wizard UI, there would be an increased probability of omitting crucial steps. Usual layout resembling step-by-step process also includes progress indicator in the top part. It encourages completion and informs how much effort is needed to finish the inputting process.

Wizards also play the role of the guide, which pays attention to the validity of the entire process and take care of the dependency logic. Meaning, some inputs in a separated steps are dependent on each other.

Wizards are beneficial only when using occasionally. Their frequent usage would annoy people that gained significant skill in using your app.


#5 Use the social proof to retain confidence

Sign up form is the first part of the onboarding process. Usually comprised of two input fields, social login, and a confirmation button. Few minor improvements can help with a drop-off and increase conversion. However, the redundant white space around the form is a missed opportunity. To preserve forward momentum this white space could take advantage of static elements that reinforce connection and trust in the concept. But doesn't cause a distraction driving user’s attention away from the main journey.

The simple solution to add a fuel to the engine is to incorporate social proof. Here are the 2 Common Social Proof types appearing on Sign up screens of starting projects:‍

1. Safe place to be - Testimonials from happy users simply works, because people can relate to statements of others. If the quote says something along the lines user's mind is searching for, then the user feels that she is at the right place. Pull out the content from tweets, emails and forum comments showing the excitement your solution brings.

2. Bandwagon effect - Expressing the quantity in interaction happening through your platform creates an impression of working product. Pull out the statistics around objects your app manipulates with. Show the number of projects/tasks created by users, github repository stars, exchanged messages, sent invoices in total, profiles created and etc.

It doesn’t seem so, but sign up screens can vary in complexity. If your Sign up screen must include additional input fields because of contextual requirements, social proof can play the role of a reminder, how useful the product is.


#6 Main navigation comprised of domain entities 

How do we decide, what to keep in a menu and what not? What is “important”?

Every SaaS is basically a system that enables the user to perform actions upon objects. Actions usually alter the state of the object.

In every situation, there will be more actions available than objects/entities. Consider collaboration SaaS and “Project” as an object. A user can create, edit and delete the project. At least 3 actions are possible within 1 object. Therefore in order to keep menu concise, objects should be part of the menu, not actions.

Further reading:
How well structured menu decrease costs by cutting support tickets in half.


#7 Align with users' approach to decision making

There are only two types of dashboards you can have in your app, Operational and Analytical.

1. Operational Dashboards
‍Use when users have to react immediately based on the realtime data. Engagement in time-sensitive tasks is a key factor to be considered. Purpose is to create a control room where activity of all the actors within a system can be seen and UI navigates us to relevant action. Imagine a dashboard for a fleet management app, where all vehicles within a fleet are tracked. Or project management app that provides a preview of all the projects various teams work on now and how they approach the finish line.

2. Analytical Dashboards
‍Use when users rather need to gain insight and perceive critical relationships between data. What counts is the quality of the judgment. Longer time periods are considered in this context. Overview of distinct business parts at once helps to outline the trends and provides playground for the analysis. Classical example is a tool for tracking user activity and key metrics measurement. Or advertising performance analytics software.

Mixing these two types together demands different decision making capabilities, which are contradictory. These can cause misinterpretation of signals and inability to react at the right time.

Designed with Mobirise html themes