Why you need wireframing to validate your product design ideas

• Validate, wireframing
why-you-need-wireframing-to-validate-your-product-design-ideas

Gone are the days of validating a new product idea by sketching it out on the back of a beermat. Users of this day and age are much more demanding than that.

Nevertheless, we still see too many tech founders and developers skipping that critical practice of wireframing and jumping straight into interface design.

This is all well and good if you want to get a product in front of people before you’ve even put your pencil down, but the number of user requirements that can get neglected with this approach can be extremely detrimental to its overall success.

Let’s take a closer look at the concept of wireframing and why it should be part of your product design process:

What exactly is wireframing in UI design?

A wireframe is the proverbial architectural blueprint of a tech product. It affords you the opportunity to define the basic structure of the product and organise the hierarchy of its user interface (UI).

Defining the basic structure and hierarchy with wireframing

The basic purpose of wireframing is to depict the overall functionality of the product itself, so it will show things like navigation, data visualisation, buttons and general layout. It’s an incredibly effective way of visualising the manner in which the interface elements will appear on the most important screens to your users.

This way, you can define the fundamental structure of your tech product in order to get early sign-off from stakeholders and other colleagues that confirm you’re heading in the right direction before you start the creating the visual design.

The danger of avoiding wireframes as an early-stage tech company

It happens time and time and time again.

Tech founders and development teams skip the wireframing phase in favour of getting to the point of launch as quickly as possible.

It’s easy to understand why. Limited resources for most tech companies mean that it’s often difficult to justify the time it takes to get wireframing right, so they jump straight into interface design.

This can cause a raft of revisions that you just don’t need further down the line – it not only creates the possibility of extra work, but obviously extra time and money, too. What’s more is that it inevitably creates an inferior product that is too complicated and unsatisfying for people to use.

The reason we wireframe is to define the structure of the tech product so that we can iterate and modify much more fluidly throughout the process. It encourages discussions about how the product works, how the screens connect and how the structure of the interface appears to the users, which means opinions can be aired as early as possible and structural changes can be made as smoothly as possible at almost any stage.

Low-fidelity wireframes can confirm the validity of your product ideas

In my experience, low-fidelity wireframes are the quickest route to defining the structure of a product to be able to put it into early-stage user-testing.

This is typically the way in which you can get early confirmation of the validity of the idea from the likes of stakeholders, so it’s a crucial step towards the realisation of your design vision.

Utilising low-fidelity wireframes to validate your design ideas

It’s a smooth and straightforward process that’s easy to replicate in your tech company as it provides a platform for feedback at the right stage of the process. If it is treated like a continuous feedback loop, you will eventually get to the stage at which all stakeholders are fully onboard with the way in which you will be addressing the problems you are trying to solve for your users.

How to create wireframes that work

Creating your wireframe and developing the prototype

There are a few different approaches you can take to this process, but low-fidelity wireframes tend to be the most efficient way of getting it right without eating up a tonne of time whilst you’re at it.

It sometimes helps to physically draw your wireframes out in the first instance. You will, however, need to translate them into a digital format at some stage; I’ve created a selection of printable A4 frames for various devices and browsers to help get you started – you can browse them here.

Printable wireframe templates by Simon McCade

Once you’re ready to convert them, there are many useful, simple tools you can call upon, too; take a look at my personal favourites, Balsamiq, Figma and MockFlow.

One of the great benefits of creating your wireframes in this manner is that it forces whoever is reviewing them to focus on the functionality rather than the aesthetics. If there is no visual design to the tech product at this stage, people can’t get caught up in that level of detail. This means you can concentrate on what matters at the right stage of the process.

The key focuses here should be on forming the structure and navigation of each screen, including the architecture and hierarchy of the content you’ll be displaying.

Once you’ve defined those elements, you can take it a step on by building a simple prototype that allows you to connect each screen for an interactive user experience.

At this stage, you don’t have to worry about the actual visual design, since the clickable elements of the prototype will do enough to simulate the experience for your users. This way, you won’t be reliant on their imaginations when it comes to specific flows through the product and you get more valuable feedback.

Prototyping your wireframes might well take a little more time, but it is always worth it further down the line.

Testing wireframes with users (and stakeholders)

The all-important first testing phase is a crucial one to getting it right. You need to include the right people and this doesn’t just mean your stakeholders because they might be breathing down your neck; it means your actual target audience.

Testing with real users to define the trajectory of your tech product

Your potential end-users will provide the most honest and insightful feedback you can imagine because, of course, they don’t have a stake in your product. They are the ones you will want to onboard, so you need to make sure you show them how you can provide value and solve their problems right from the off.

When I put the products I design through testing, I take the kind of informal approach that guides stakeholders and users through the thought-processes behind each decision.

This means asking them to perform specific tasks that have been designed with the best possible user flow in mind. It means asking them for feedback and opinions either individually or by opening up the floor for a discussion.

It’s important to keep in mind that feedback on products like these can often be subjective, so they need to be taken away from such sessions and digested with any potential preconceptions they might have had in mind.

Once you accept that preconceptions will influence user feedback, you can take only the most valuable learnings from testing sessions

Digesting the feedback

Now comes the workable aspect of getting users involved at this early stage. You can delve into their feedback, whether it’s been provided in note form or you’re using a tool like Figma, and analyse each individual screen and how it was received by your users.

It’s then time to prioritise what is worthwhile discussing, what needs to be actioned and what can be ignored.

Collect, analyse and action user feedback to improve your tech product

The wireframes can then be adapted with genuine user requirements in mind, but try not to cut the corner by stopping there; this user testing can be repeated as many times as is necessary to get it absolutely spot on as early as you can before the visual designs come into play.

It might seem a little laborious to begin with, but the amount of time, money and effort you could save down the line will be a real blessing when you see real-world feedback from your actual users.

How I can help you wireframe

The benefits that wireframing can offer far outweigh the reasons for not including it as part of your product design process, but it is understandable that it isn’t always easy to find the time or experience to cover it.

Even if you can find the time, it might often be a struggle to simplify your product and increase conversions as part of your long-term plan for a sustainable product.

That’s why I’m here to help if you are looking to design or redesign your tech product with the expertise required to meet and exceed your users’ expectations.

Get in touch today and we can arrange a consultation to discuss your needs in a way that suits you.

‍

Validate forms with validate.js

• forms, Validate
validate-forms-with-validate.js

Introduction

In this tutorial, you will learn how to implement form validation using validate.js library.

You will learn how to add dependencies, build basic form structure and execute required functions to create fully
validated form with custom error messages and dynamically assigned errors depending on which type of error user
caused in your form.

Note: To understand this tutorial content you need to have some understanding about JavaScript and HTML’s form structure. I will do my best to explain everything in depth but you need to have some basic knowledge about this topic to use this useful extension.

,,Why should I waste my time for this?”

Validate.js is a lightweight library that depends on object constraints and function validate(). This simple structure gives us easy to understand logic about our rules of validation inside the object and receiving errors depending on our custom made rules with a designated function. After this tutorial, you will understand everything you need to build your first validated form with this technology.

See how easily you can modify your design of the form keeping the same validation methods.

Installation

To use validate.js you actually don’t need any external dependencies! However, you might want to add a way to
validate date and DateTime with custom parse and format function. For that purpose creator of
validate.js
recommend
using moment.js library.

Additionally, to show you we can use only clear javascript while using this library I will not use any jQuery
code
in this form aside initiation of our MDB components. To make this process easy I will use some basic functions
from underscore.js
to quickly operate on dom elements without building any external objects and functions.

My starting index.html file will look like this:

Note: You can use validate.js library without any other dependencies. I
will use external dependencies to show how you can implement complex form easily by using these additions.

Build an MDB Form

To check if the form is properly filled by users first we need to have a ready form.

In this tutorial I will try to showcase all the possibilities of this validating library, so we will need a variety of
input types.

This example showcase usage of basic input types like type="email", type="password",
type="text", type="date" or type="number" and additionally, some custom made
validation will check the validation of the select field.

To present how you can implement this validation in the real-life example I styled this form and prepared space in
bootstrap layout for errors display.

Note: Elements with class .messages will contain error
content.

The form that I will check with validate.js looks like this:

Let’s get started!

Step 1 – create constraints object

When working with validate.js this object is essential. Inside this structure, you define what attribute of input you
want to check, what input types you want to be checking, check your custom validator options and many more like
defining error messages.

We will use object constraints inside basic validate function of this library but let’s not overtake the topic.
First, we need our rules.

The basic structure of constraints object looks like this:

To create complex constraints object you have to consider all use cases of your form.

In my example form, we have all sort of different input types so we need to create constraints rules for all of
them.

Note: Element attribute is, in this example, the name tag inside our input
declaration. Validator name is one of the predefined names given by the library. Validator options are one of the given
values that given Validator name accepts.

Basic elements

Checking email

Validate.js is created by making our development easy in mind. Creators made commonly used features available to
use by default. For example to create constraints for basic email checking you have to create only these lines of
code:

Checking password

Checking if the password is enough long for our standards is simple and easy to:

Confirm password

This sometimes causes troubles during development but with validate.js you simply use default options given by the
library. We have the attribute equality which gives every possible feature you might need in checking equality of
your input fields.

To check if this element value is equal with another input type we need to create a structure like this:

In the HTML form I used the intuitive name for input that will require confirmation of the password but this name contained symbol ‘-‘. Because of that, we had to show the object that we still work with the name string. To accomplish that I simply wrapped the name of this validate attribute inside a string
apostrophe’s like this:

"confirm-password":

In this example, we created a custom message for our new constraints rule which is ‘equality’. For email and password validation we have predefined messages that we can use if we want to but for our custom rules, we have to create our messages that we want to display in case of an error.

Note: Creating custom messages might be useful to create different language versions for your form validation.

Check the input content – Username

In our services we want our users to have standardized usernames. We can create this sort of in-depth checking with validate.js. In my example, I will require username to exist, have a length between 3 and 20 string length, contain only letters and digits but we don’t want to check if letters are upper or lower case.

With standard validation options, we most likely would create a complex function that would check all these elements by parsing our input value. With validate.js you can accomplish that by simple object structure:

In the example above I tried to explain every element used by adding comments. Because of this object great structure, every part of the required code is easy to understand and after the first implementation, everything seems to be intuitive.

Note: To find out every possible predefined attribute you can check their list in full documentation on the creator’s site.

Age restriction – Date

This kind of verification can be achieved by a countless amount of ways. In this example, I will use the library that I mentioned at the beginning moment.js. This addon makes my birthdate verification 4 lines long:

Like always we check if the element exists with presence: true,. This time we need to use default date attribute and check it with the latest value to ensure the data we get in the date input is not later than the declared value.

This may be not intuitive but using the function moment().subtract(18, "years") I check what moment it is right now and what is the year someone had to be born to be at least 18 years old.

Because I declared new validation rule I declared additional error message if this rule is not fulfilled.

This is that simple!

Checking select field – Country

This part will demonstrate how to implement validation with our mdb material select. This component causes many troubles in the past with validation implementation but with validate.js it is much easier.

In the form I created to demonstrate this type of validation you can see that the list of options is quite large but every single one has an attribute: value="" with country code in it. Because of this addition, we can check what option is picked more intuitive.

In this example, we used two new attributes: inclusion and within.

Inclusion checks if the input value is the same as any element from the “within” table. In this example, I declared only a select option with attribute value="SE" which is Sweden.

Note: Inclusion gives you the opportunity to check if the input value matches one of many options you declare as valid. Simply extend it within the table with more strings separated by a comma.

We almost finished, let’s understand the last two types of constraints declared in my example.

Checking optional field – Zip Code

In declaring constraints I used presence: true in all examples above but this element is not required to exist in every single validated attribute. This time I present you simple constraints example of how you can check if the validated input fits your rules.

This time my declaration want this input to contain 5 digits. I achieve this validation this way:

As you may notice in format attribute we use pattern with value wrote using regExp to declare what type of string we accept.

Note: To read more about this element visit this documentation site

This input will not be validated unless someone types something in it. If at the moment of checking the form value will be empty there will be no verification of this input but if the content of the input exists and doesn’t match our pattern rules the user will receive an error message.

Checking number field

The last element we want to validate is number input with restriction to accept only an integer value equal to or greater than zero.

Achieving this with validate.js is simple:

Code in this example basically explains itself. After watching previous examples this one is trivial, isn’t it?

To check numerical values we use to attribute numericality with some basic expressions like “only integer” and “greaterThanOrEqualTo”.

Note: To read more about numerical validation rules check this documentation site

And… We did it! Our Constraints are ready to be validated.

Validation in action

Like in every form we need to add some basic js functions before we start creating our features. In this example, I create an extended validation rule for date checking to accept the desired format.

After all my rules are ready to be used I hooked up the form to prevent it from being posted and instead execute a custom function.

After the form submits event my handleFormSubmit() function will be executed. Let’s create this function now!

This simple function checks if validating function after checking our form returns any errors according to our predefined constraints. We execute function showErrors() if any error exists or showSuccess() if there are none.

Let’s create both functions:

Inside our loop, we execute the function for every single input to show it’s errors and as explained in comments, we have to handle errors that contain null. To achieve that we create the function showErrorsForInput() that will do exactly that.

This function will be more complex so let’s read this carefully with my comments:

In the function above we use functions closestParent, resetFormGroup, addError and element item but we didn’t declare them before. Let’s fix it now!

First, we create the input variable:

In this code, I created not only an input element but additionally a loop that will iterate through all inputs that we find and proceed with some intentional methods.

We want to know if any input was changed and if that is a truth we execute code inside this event function. Generate new errors depending on this state of form and execute a function that will show this direct input new error.

Now I will declare a function closestParent(). We will use this function to find a place for our error messages. My structure of HTML assumes that my errors will be displayed inside of a grid structure so I just need to reach a div that is a sibling to our inputs div with class .md-form.

This function will look like this:

We just check if the attribute child received an element that can actually be a nested element and if that is true, checks if this element contains the class that we want to actually find. If not we reach .parentNode element and execute the function once more. So the only expected outputs are null if we reach document without finding the desired class or actually an element that we are looking for.

Our form validation is almost ready. The only missing parts are functions resetFormGroup and addError.

To achieve reset of a form group we just clear previously added classes and remove elements containing errors.

So, for now, we check our form and take care of all the possible outcomes but we didn’t add the main part of this whole event. How actually we add our errors to the form?

Check out this function:

And that’s it. We just have to assemble all the pieces and execute them in (function() { })( ); object.

I added one mdb element to the mix so we have to initialize MDB material select with this code:

It is done!

We created a fully functional front end form with various validation methods and our custom set of rules. Our final result should contain this code:

Conclusion

Validate.js is helpful library to create all sort of validation rules and complex solutions. You can customize every single point of your form without hesitation. If you don’t want to build jQ dependant form validation with our MDB Package I highly recommend using this library to build your own form constraints.

Note: Don’t forget to show us your form with custom validation in our snippets