As developers, we create applications to help the society do things easier by digitizing what we do everyday. For example, we help people do transactions by digitizing money so that they do not have to do the hassle of going to the ATM to do the transaction. But we can’t just go straight into designing and interpret everything by ourselves. We need the help of other people, especially who will be the end-users once we’ve delivered our application. This theory is called User Centered Design.
User Centered Design
“User-centered design (UCD) is an iterative design process in which designers focus on the users and their needs in each phase of the design process.”
The main idea of UCD is to involve end-users in the design process of our application. The purpose is for designers to understand user needs and result in a usable product to them. So basically, understanding the whole user experience. The UCD is done in an iterative process which consists of four phases:
- Understand the context of which the user uses the system.
- Identify and specify user requirements
- Design based on requirements
- Evaluate design against requirements
The first step of UCD is to understand the context of which the user may use the system. After that, we try to identify and specify user requirements based on the contexts we understand. Based on the requirements specified, designers then make the design of the product. Once the design has been made, we evaluate it and check how the design works based on the context and requirements specified in the phases before. If we feel that the design is not close enough to the context or user requirements, then we can do another iteration of the phases until we are fully satisfied that the design is enough to meet the context and user requirements.
How We Implement UCD in our Project
Understanding user context
First of all, we have a meeting with our client (Badan Pengelola Keuangan Haji, or BPKH) which will be the user of our product. The purpose of the meeting is to gain an understanding of the context of what the users may use the system which is the first step of UCD. After the meeting, we discuss together our understanding of the user’s context and create a persona to just have a written version of our understanding.
So, below is an example of a persona made for the user which is a BPKH staff that wants to digitize their monitoring and evaluation reports of their projects. In the persona we describe who the user is, what the user’s goal and motivation for the product we are going to deliver and the user’s frustrations as to why the user needs the product. We also do the same for every other users that will use the product.
Identify and Specify Requirements
After we’ve done making the personas of each user, we then identify and specify the requirements from the personas we’ve made. The requirements are made in the form of product backlog, which is a list of features that will be implemented in the product. One major feature is the ability to create a monitoring report from the product.
Design based on Requirements
Once the requirements are identified and specified, it is time for the designers to create the product based on the requirements specified in the last phase. Below is an example of the design we made for one of the major feature which is the ability to create a monitoring report.
Evaluate Design against Feature
Once we’re satisfied with the design, we evaluate it again to see how much of the design covers the requirements. We do this by going through each requirements again and again while also confirming that each requirement has been designed accordingly.
If a requirement has not or incorrectly designed, we can go back to the design phase to rework the old design into a design that matches with the requirements. Once we feel satisfied with the results, we consult back with our client to get feedback and reevaluate to see what can be added or changed. Once the client is satisfied, then we can start going into the implementation phase (which is not a part of UCD).