This project was done as a part of course project in masters programe in Human Computer Interaction.The project was done in a group where all of the members participated equally in all the activities.
The course is called "Requirements in Agile Development" and the course is about :
"Application of theories from human-computer interaction in agile software engineering processes to develop computerized systems and tools that correspond to intended users' needs."
Introduction - The Flexible Cashier
In this project we’ve looked at the register system used by a nation to sell food and beverages in the restaurant and pub. By following agile development process, modelling different artifacts and contextual inquiry we have highlighted breakdowns in the existing system and suggested improvements.
PROCESS
Initial Interview - Understanding the work
In order to understand how the system works and how user perform activities we conducted an interview with one of the employee (curator) who works with the system.The purpose of this interview was to look at different parts of the work and then identify what needs to be improve.
Contextual Interview - environment and context understanding
After the initial interview we decided to specifically look at one of the main part of the work which is "register system" where the curator register food items to sell.
During contextual interview we looked at how different activities are performed by user in real environment to understand how they structure and perform the job they do.
Interpretation Session
After contextual interview, the data we gathered was analysed and we highlighted key elements of work practice, user objectives, pain points and workarounds.
Work Models
After the contextual interview we build different work models for organized representation of the
physical environment where the work happens, and the artifacts people use to accomplish it.
Following work models were developed:
-
Artifact Model
-
Flow Model
-
Sequence Model
Ideation
During ideation we visioned how the work could be done ina better way with new tool and documented our vision in the form of UserStories and storyboards ,which were then evaluated by user
Prototype
Finally after userstories and storyboards we developed the prototype and implemented the changes. which was then presented to user.
Appendices
Initial Interview Notes
ARTIFACT MODEL
FLOW MODEL
Third curator:
In charge of the restaurant business in the nation. Setting menus, prices and ordering all the food.
Workers:
They are the ones working in the bar and the kitchen, preparing and selling the food.
-
Exchange 1: They can come to the curator with a proposal for a new entry on the menu. The curator adds it into the system (by programming relevant buttons) so that the workers can prepare it with physical ingredients and sell it.
-
Exchange 2: A worker might encounter a problem with the system. They report this to the curator, who then tries to solve it
Food Supplier:
They are the food suppliers and deliver the food to the nation.
-
Exchange 1: The curator places an order, and the food supplier delivers it.
Software Support Team:
A company is supplying the cashier system. Both the system on the curator’s computer and the smaller computer used by the bartenders taking the orders from the customers.
-
Exchange 1: If the curator encounters a problem that she herself cannot solve directly, she will need to contact the IT-support at the software company so that they can fix the problem or guide the curator on how to fix it.
SEQUENCE MODEL
Order Food and Calculate cost price for new menu item
Entering menu-item in the register
Adding a button
USER STORIES
-
As a Third Qurator, I want to add new dishes to the menu, so that our customers can enjoy avaried pub experience.
-
As a Third Qurator, I want to add new dishes to the register, so that our bartenders can sellthat dish in the pub.
-
As a Third Qurator, I want to add different prices to each dish, so that our members andpersonnel can enjoy discounts.
-
As a Third Qurator, I want to add a zero price option to each dish, so that our register can keep track of all food that’s consumed during the day.
-
As a Third Qurator, I want to know what each dish cost to create, so that I can set a selling price with an appropriate kickback.
-
As a Third Qurator, I want to keep the registers easy to use, so that our new bartenders canuse it without any experience.
STORY BOARDS
Calculating prices
Adding Dish to register
Add and programe button to sell
PROTOTYPE
Due to time limitation we did not had time to completely rebuild the whole design instead we decided to use the existing system screenshots to show the changes we want to implement.
This is the Main Screen of the system
Problem 01 : Repitetion of steps
To programe a button there are multiple attributes of buttons which needs to be configured e.g (changing the text, the color of button, adding macros to the button etc). and for each button all of these steps have to be repeated.
Solution : Copy button feature
To solve this issue we decided to add a copy button function so that the user can copy the existing button with all the attributes and change only those attributes which needs to be changed.
Problem 02 : Alot of nested windows
As it can be observed in Artifact Model that there were a lot of nested windows (programme a button, search article , change appearance etc.) in the system which can lead to cognitive overload and increase the number of clicks to complete the task.
Solution : No more nested windows
To solve this issue we decided to make the right portion of interface dynamic which means the content of nested windows will appear there following the most common structure in many applications.
When clicking on Programe window button text and other attributes can be configured as seen below
User can also access other features like adding macros on the same screen
Further different article (Menu-Items) can be searched on the same place to link.
Problem 03 : No fixed Order for programming a button
One of the potential breakdowns in the system as highlighted in sequence diagram (Adding a button) was that there is no fixed order or sequence in which button should be programmed which can be problematic as user can miss out something or it can also be difficult to keep track of what has been configured and what not.
Solution : Adding History
This problem was solved by introducing the history section as shown below where user can easily keep track of their actions.
Problem 04 : Undo/Redo
Currently there was no easy way to undo/redo actions performed by user while programming a button.
Solution : Adding shortcuts to undo/redo actions
So we suggested to add shortcuts ctrl+z and ctrl+y to undo/redo respectively so user can view the history and if he/she wants to reverse the action they can do it easily.
Problem 05 : Repetition of steps
Another breakdown of the system which was highlighted in the sequence model above (adding a menu-item in register) is that for each menu item the user has to create four variations with four different buttons and all the steps needed to create a button are repeated for each variation where the difference is just in the price of item.
Solution : Display variations automatically in a new dialog box
We added a dialog box where the system will get all the variations of a menu-item from the register and will generate a button for each of the item as shown below.
As it can be observed in the image below after user adds a button for new dish which in this case is "PastaLemon" a dialog will appear upon clicking on the button which will show all the variations of the dish from register database.
