Vi SuA L. D e SiG n.

[It’s ya boi back at it again with another one]

Now, to reiterate the statement I’ve said in another article,

Design is undoubtedly the most important part in Software Development

Since the aim of the development is to be able to be used by many users, how can we make sure that those users would have a good experience of our product and know what we are offering to them? If you thought of making wireframes and mockups, then you are correct. Here I will explain to you what they are.

Image by: Source

Wireframe

Wireframe, what’s that? Well, a wireframe is what we call a low-fidelity design layout. That would mean that a wireframe only shows the idea of the design and an approximate of where everything would be placed, a skeleton if you will. Wireframes will be comprised of 3 purposes, which are:

1. Represents things that will be displayed. Every detail in the design would be simply represented by a placeholder, such as large squares with a short description on what is what, to at least show where goes what. It should be in a minimal amount.
2. Outline of structure and layout. The wireframe is only a skeleton hence all you need is a simple outline of the layout without any detailed designs or colors filled in.
3. Overall design direction and description. Since the wireframe will then be used to conduct a UT they should at least be able to show where the design is going when they are implemented.

Below is an example of a wireframe and a snippet of the one we made for our project:

Wireframe of Landing Page

From the image above, you can see that we have followed the 3 guidelines on creating a wireframe:

1. Keep grayscale colors. Since it is just a skeleton, there is no need for detailed colors.
2. Use a maximum of two fonts. The fonts are mainly used for the small descriptions of what each structure represents. There would no need to have more than two fonts, even wireframe.cc only have one font.
3. No images or any fancy details. Remember, it’s a skeleton and we are using placeholders to represent images and some other details.

Mockup

Now, normally by the time you have reached the mockup, the wireframe should be done already. As you can guess, a mockup is a high-fidelity design layout. Although it is a high-fidelity design, it is not yet the final product, but it should at least either resemble the final product or nods to the direction of the final product, a design is iterative after all. Of course, mockups bring about benefits such as:

1. High-fidelity. It is a version in which the final product can be captured from.
2. Realistic. It has some details that were not in the wireframe such as, color palettes, images and detailed designs
3. Revision friendly. It is easier to revise a design by looking at it rather than trying to revise a design from the code.

From our project, we’ve had at least four (4) revisions to date, which were mostly caused by UT and internal testing, but this is the design that we have chosen to base the product off of.

Although, we were tasked to make three (3) designs, due to the time constraint and schedule of a student, we could only focus on one at a time. This design is among one of the decent ones created, but as of the time I am writing this, our hacker Andre should have given the design a few improvements to it.

Usability Heuristics

During the design process, we also made sure to pay attention to the ‘Usability Heuristics by Nielsen’. Which are comprised of some broad principles on the usability and user interaction of a design. Those principles are as follows:

1. Visibility of system status. The system should always keep users up-to-date with what is going on, by appropriate feedback within reasonable time.
2. Match between system and the real world. The system should use language and concepts that is familiar to the user.
3. User control and freedom. The system should support an easy access to undo and redo as the user want.
4. Consistency and standards. Users should not have to wonder if different situations would mean the same thing.
5. Error prevention. Eliminate error-prone conditions or check them and confirm with the user before they do an action.
6. Recognition rather than recall. Minimize the users need to memorize how to do certain actions or information.
7. Flexibility and efficiency of use. The system should be able to be used by both experienced and inexperienced user.
8. Aesthetic and minimalistic design. Design should not contain irrelevant and/or unclear information.
9. Help users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language precisely and should suggest a solution.
10. Help and documentation. Provide a manual that helps users regarding any problems they might face.

This article has discussed the design method our group has used and the principles that we have implemented into our design. With this, the creation of the final product has been made easier and faster. Hopefully this can aid with the creation of wireframe and mockup. With that, we have reached the end of this level. I would hope to see you on the next level and for that,

I bid thee adieu.