Planning Before Doing: Wireframe and Mockup
Before we start developing something, we need a plan about what we’re doing and what is the expected result from the project. Same as developing a website, we need to create a mockup before we start developing (coding) because it will cost so much if in the development the design changed frequently.
When creating the plan, we need to follow the procedure that needs to be done if we want it to be organized. Just like that, when we’re creating a mockup we can’t just directly designing the home page or another page, but we need a lower-level design which is the wireframe.
There’s plenty of application that providing the canvas for design the wireframe, one of the most popular is wireframe.cc.
But for our project, we decided to create the wireframe based on a hard-copy or using a paper. Take a look at our first wireframe design below.
After designing the wireframe and already sure about the placement, we can start developing the mockup. There’s also plenty of app or websites that provide tools for creating the mockup, like Figma, Sketch, and Adobe Xd. For developing our mockup we use Figma because of a few reasons which are Figma can be accessed using our browser (Adobe Xd need to be installed if we want to use it) or using their apps in any operation system (Sketch only can be used in Apple ecosystem).
When we creating the mockup, there are a few rules that we need to implement if we want to maintain the user experience, called Neilsen’s 10 Usability Heuristics that developed by Jakob Nielsen with Rolf Molich.
Nielsen’s 10 Usability Heuristic
There are 10 rules that pointed out and I will try to explain it with the example of how our project group implementing it.
Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Our homepage is a dashboard where users can easily get as many as the information they wanted. We also provide the notification at the navigation bar just in case the user missing some important information. If there is something important shows up, the notification icon will be added with the red-dot in the top-right icon so the user will easily recognized the event.
Match between system and the real world
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
We trying to use the icon to representing what actual the feature comparing to the real world. Take a look a the report icon, in the real world we will have the report by a bunch of paper and it’s already represented by the report icon (file icon). Another example is the notification, it represents by a bell because in the real world we will easily recognize the bell sound as a notification if there’s something happen.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
User needs to know where they are and want quick access for undoing what they have done. As an example, if the user going to homepage and clicked the wrong button, it will be easier if on that page has the back button to go to the previous page. In our project, we trying to implement it in add member form in the setting page. To make user navigation easier, we provide the back button with the title of the previous page so the user will know what it will do if they pressed the button.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing.
For maintaining our consistency in design and implementation, we build the design guidelines first before we started the project. It helps us to save time or even made a component that can be reused by other components because we already have a big picture of the result before we start the development. Here’s our guidelines snapshot or for the full version and also the implementation, you can check it on my post “Stay Consistent, Stay In The Guideline” in my profile.
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
We can prevent some errors to minimize the resource but it has to be as informative as possible so the user can know where is the error causes. The example of our implementation for this point is when the admin trying to add a new member to the setting page. The user will be given a form that all the field needed to be filled and if there’s some field that admin forgot to fill the field will be colored with red and shows the error message which is that field is needed to be filled.
Recognition rather than recall
Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Saving the state of user definitely will raise the user experience when using our product because they didn’t need to remember all the steps that they already have done. For our project, we implement this point by creating a setting page for change user accessibility for the data. If we click the edit button, it will show the list possible for the accessibility and will automatically save the data without reloading the page if the user clicks the save button.
Flexibility and efficiency of use
Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
In our project, we trying to give as many features as we can with the good interface so any kind of user can use the website. Take a look at our dashboard in the left and right columns. The right column will show the camera data selected from the left column if it’s checkbox is checked. It doesn’t need a request to server again because we already got all the data when processing the page for the first time and we just need to use some function to do the calculation on the component file. When the user hits the checkbox icon on the left column it will directly call a function to do the calculation and also updating the right column. It’s easier to understand by novice users or even expert users.
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
We’re trying to keep the interface as simple as possible with still trying to maximizing the information given. The dashboard is full of information because we want to make user navigation easier to access all the information needed on one page but still we try to minimize the design or the text that doesn't necessarily. Another example for this point is the login page, where we just show a card containing a login form consist of email, password, and also login button. It’s simple, still consistent with the guidelines, and also easy to understand.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
With all the prevention before, there will be still an error that will be occurred after processed on the backend server. In this case, the error information is needed to pass to the user so they will know what kind of error happens and what caused the error. Take an example of our login system, if the user fills the email and password the frontend system will not detect any error, but after it sent a request to the backend server for authentication and the credential given is invalid, we will give the notification on the form so the user knows what happens and retrying to fills the email and password correctly.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
All the lists of what users can do or even a simple error handling are needed to be documented and can be easily accessed by the users. But until this point, we still not implement the FAQ page because our client has set the prioritize features that needed to complete first. But in the end, after all the features implemented well, I think FAQ is one of the most pages needed because it can guide our users to use our website properly.
Conclusion
It seems to be fun when creating the wireframe and mockup but actually there are many things to be considered when we chose a design. User experiences are important because who will be using our website are the user. We need to make it user-oriented for providing the best user experience but also still keep the design as the product branding.
