Contextual Diagrams
In order to gain an understanding of the project in front of us, we made five different model types for each stake holder in relation to our application. There is a Physical, Flow, Sequence, Cultural, and an Artifact Model. Each of these models has three parts, one that corresponds to each of our three stakeholders.
Physical Models
Physical Model Explanation
Physical Model—User: Description
This model portrays the physical environment and how it affects the user (or customer). The areas labeled
“T1, T2,…T12” represent the tables customers sit and receive service at. Beginning at the bottom right corner, we can see the first appearance of the application in use; physically, the user is not yet inside the restaurant, but they are within the proximity required to connect with the restaurant and put their name on the wait list. The user is also very close to other shops as well. This makes it easy for the user to occupy themselves with something else, if they are close by and still have some time to spare before their table is ready. As the shops are right next to the restaurant, they can walk to the restaurant just as the table should be ready. Next, the user arrives in the parking lot, and moves from the lot to the entrance. The proximity between the parking lot and the restaurant is very convenient. As the user enters the establishment, they pass through the waiting area to reach the host stand where they see a sign #2 which indicates their party to wait for the host/hostess. The user then is directed in one of two ways: their table is ready and they are seated, or they must return to the bar/waiting area until they receive a notification from the host. If the user returns to the waiting area, seats are available for comfort, and menus are provided on a side table for entertainment/ visual distraction. If the table is ready, the host sends notification out to APPetite, user receives it, and they proceed to the host’s stand. The host them brings them to their table, in this case table T6. The spacing between tables on the floor provides a comfortable, organized ambiance, and the tables can each conveniently fit a significant amount of guests, marked by the lines surrounding the tables. Before paying, the customer can show APPetite coupon to waiter from their table. Users can easily navigate through the table aisles to the restrooms, located at the far right side of the restaurant. Sign #4 outside of the restrooms serve as a visual aid of navigation to users. Around the restaurant, clocks are visible as visual aids, and, if needed, the user can access a telephone at the bar. Other visual references are sign #1, the entrance sign, and sign #2, the “employees only” sign. Prior to the interviews, the layout was set; the only thing the interviews really changed was the addition of a waiting area to increase space on the restaurant floor, and the addition of take-out menus to keep waiting customers preoccupied. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
Physical Model—Host/Hostess: Description
This model shows the physical model in relation to the activities of the host/hostess. The host arrives at work through the main entrance; they also come from the easily accessed parking lot. They report to the host stand, and begin managing the floor via the computer from the desk. From the stand, they can manually enter customer names for the wait list, or, if APPetite is used, the names are automatically entered, which makes their job easier. In order to notify a non-APPetite guest, the host moves from the stand, to the waiting area/bar and verbally calls/greets party then proceeds back to the stand. To notify an APPetite user, host sends buzz-notification from the convenience of their stand. Once party is notified, they proceed to meet the host at the desk. Host retrieves menus from either side of their area, and, in this case, guides party to T2. The numbered layout of the tables serves mostly as the host’s organization guide. After parties are seated, host moves to the “employee area” to notify wait staff of floor information. Here the host can also take a break, use the telephone, and store/access personal belongings in the storage area. Similar to the physical model for the user, clocks and signs serve the same visual reference use. An additional telephone at the desk is designated solely for incoming restaurant calls/business purposes. From the interviews, we learned to incorporate a telephone at the hostess stand, and storage space for menus/the computer to ensure productivity. The wait area also was added to de-clutter the area around the host stand/bar to facilitate smooth navigation. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
Physical Model—Restaurant (Owner/Manager): Description
This model provides information regarding the effects of the physical environment on the restaurant (owner/manger) activities. The focus of this model incorporates more activities from the restaurant to the outside world compared to the other models, in addition to a few managerial roles within the restaurant. Here our restaurant is located within a strip mall in close proximity to stores and a food court—meaning potential customers pass the restaurant frequently. Stores provide customer wait-time entertainment, and also pedestrians within the stores are often drawn to the restaurant due to the location. Furthermore, the food court on the left side of our restaurant heightens competition. The proximity of the parking lot to the restaurant within the strip mall attracts customers and is also convenient for the staff. At the front of the restaurant, large windows range from wall-to-wall facing outward into the hallway of the mall. These windows provide great visibility inwards and outwards, and the walls between the restaurant and the food court/stores maintains restaurant ambiance. At the back of the establishment we see a delivery area located at the kitchen—this idea was provided from our interview with manager Kristina Leach. The location of the area is great for restaurant appearance (because it is hidden in the back), and for smooth distributor-to-restaurant transactions. Trucks from grocery distributors 1 and 2 can pull into delivery area directly to drop off food and supplies directly to a door reaching the kitchen. This is great because these transactions won’t affect restaurant floor activity. Within the establishment, the manager can oversee the floor and easily interact with customers if requested. In this situation, the manager moves from the office, onto the floor and to the table of guests. From our interviews, the manager’s office was added in the employee area because Kristina Leach described most of her duties within her office. Here, the manager would upload coupons, menus, promotions, etc. to APPetite from the managerial computer. The employee schedule is also made and kept within the office as a visual aid for both employees and the staff. A telephone is also available for managerial/staff use. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
This model portrays the physical environment and how it affects the user (or customer). The areas labeled
“T1, T2,…T12” represent the tables customers sit and receive service at. Beginning at the bottom right corner, we can see the first appearance of the application in use; physically, the user is not yet inside the restaurant, but they are within the proximity required to connect with the restaurant and put their name on the wait list. The user is also very close to other shops as well. This makes it easy for the user to occupy themselves with something else, if they are close by and still have some time to spare before their table is ready. As the shops are right next to the restaurant, they can walk to the restaurant just as the table should be ready. Next, the user arrives in the parking lot, and moves from the lot to the entrance. The proximity between the parking lot and the restaurant is very convenient. As the user enters the establishment, they pass through the waiting area to reach the host stand where they see a sign #2 which indicates their party to wait for the host/hostess. The user then is directed in one of two ways: their table is ready and they are seated, or they must return to the bar/waiting area until they receive a notification from the host. If the user returns to the waiting area, seats are available for comfort, and menus are provided on a side table for entertainment/ visual distraction. If the table is ready, the host sends notification out to APPetite, user receives it, and they proceed to the host’s stand. The host them brings them to their table, in this case table T6. The spacing between tables on the floor provides a comfortable, organized ambiance, and the tables can each conveniently fit a significant amount of guests, marked by the lines surrounding the tables. Before paying, the customer can show APPetite coupon to waiter from their table. Users can easily navigate through the table aisles to the restrooms, located at the far right side of the restaurant. Sign #4 outside of the restrooms serve as a visual aid of navigation to users. Around the restaurant, clocks are visible as visual aids, and, if needed, the user can access a telephone at the bar. Other visual references are sign #1, the entrance sign, and sign #2, the “employees only” sign. Prior to the interviews, the layout was set; the only thing the interviews really changed was the addition of a waiting area to increase space on the restaurant floor, and the addition of take-out menus to keep waiting customers preoccupied. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
Physical Model—Host/Hostess: Description
This model shows the physical model in relation to the activities of the host/hostess. The host arrives at work through the main entrance; they also come from the easily accessed parking lot. They report to the host stand, and begin managing the floor via the computer from the desk. From the stand, they can manually enter customer names for the wait list, or, if APPetite is used, the names are automatically entered, which makes their job easier. In order to notify a non-APPetite guest, the host moves from the stand, to the waiting area/bar and verbally calls/greets party then proceeds back to the stand. To notify an APPetite user, host sends buzz-notification from the convenience of their stand. Once party is notified, they proceed to meet the host at the desk. Host retrieves menus from either side of their area, and, in this case, guides party to T2. The numbered layout of the tables serves mostly as the host’s organization guide. After parties are seated, host moves to the “employee area” to notify wait staff of floor information. Here the host can also take a break, use the telephone, and store/access personal belongings in the storage area. Similar to the physical model for the user, clocks and signs serve the same visual reference use. An additional telephone at the desk is designated solely for incoming restaurant calls/business purposes. From the interviews, we learned to incorporate a telephone at the hostess stand, and storage space for menus/the computer to ensure productivity. The wait area also was added to de-clutter the area around the host stand/bar to facilitate smooth navigation. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
Physical Model—Restaurant (Owner/Manager): Description
This model provides information regarding the effects of the physical environment on the restaurant (owner/manger) activities. The focus of this model incorporates more activities from the restaurant to the outside world compared to the other models, in addition to a few managerial roles within the restaurant. Here our restaurant is located within a strip mall in close proximity to stores and a food court—meaning potential customers pass the restaurant frequently. Stores provide customer wait-time entertainment, and also pedestrians within the stores are often drawn to the restaurant due to the location. Furthermore, the food court on the left side of our restaurant heightens competition. The proximity of the parking lot to the restaurant within the strip mall attracts customers and is also convenient for the staff. At the front of the restaurant, large windows range from wall-to-wall facing outward into the hallway of the mall. These windows provide great visibility inwards and outwards, and the walls between the restaurant and the food court/stores maintains restaurant ambiance. At the back of the establishment we see a delivery area located at the kitchen—this idea was provided from our interview with manager Kristina Leach. The location of the area is great for restaurant appearance (because it is hidden in the back), and for smooth distributor-to-restaurant transactions. Trucks from grocery distributors 1 and 2 can pull into delivery area directly to drop off food and supplies directly to a door reaching the kitchen. This is great because these transactions won’t affect restaurant floor activity. Within the establishment, the manager can oversee the floor and easily interact with customers if requested. In this situation, the manager moves from the office, onto the floor and to the table of guests. From our interviews, the manager’s office was added in the employee area because Kristina Leach described most of her duties within her office. Here, the manager would upload coupons, menus, promotions, etc. to APPetite from the managerial computer. The employee schedule is also made and kept within the office as a visual aid for both employees and the staff. A telephone is also available for managerial/staff use. The last aspect added in this model was the wait-staff computer area—a suggestion taken from the manager interview.
Reasons for Modifications
User:
The reasons for the changes in the user description, were that we thought there should be more integrated into the diagram than just the restaurant and the parking lot. Therefore we added the shops interaction in the diagram with the user. This is a fairly important part of the diagram and purpose of the app considering it is one of the advantages that our app gives users.
Hostess/ Manager:
No changes were made to these diagrams, because we felt that altering these diagrams would take away from the already existing purpose of them.
The reasons for the changes in the user description, were that we thought there should be more integrated into the diagram than just the restaurant and the parking lot. Therefore we added the shops interaction in the diagram with the user. This is a fairly important part of the diagram and purpose of the app considering it is one of the advantages that our app gives users.
Hostess/ Manager:
No changes were made to these diagrams, because we felt that altering these diagrams would take away from the already existing purpose of them.
Flow Models
Flow Model Explanations
Flow Model : Host/Hostess
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the host/hostess as being the most important stakeholder in this diagram. The host/hostess is the stakeholder that interacts with the user and the restaurant/manager in order to provide a table for the user. The
user in this diagram is choosing what restaurant they want, what type of food they want, and then using the application to reserve a table. The hostess/host would receive a reservation request from the user right away and would be able to use the computer to access the user’s info for the table reservation. Hostess/host would then check the availability, and ensures that the table and such needs will be present when the user arrives and the service would automatically give the user an estimated time when their table would be ready. The host/hostess waits upon the user. The restaurant/manager would receive information from the host/hostess that reservation(s) have been made. The manager/restaurant checks the status of the restaurant and tells the host/ hostess any other information if there is a change in plans or something has happened. The hostess/host also tells the manager/restaurant if something goes wrong, or needs help. The restaurant/manager also provides the user information about the restaurant for the app. The user also interacts with the manager/restaurant if they are having poor service.
Flow model: The restaurant/manager
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the restaurant/manager as being the most important stakeholder in this diagram. The restaurant/manager is the stakeholder that interacts with the host/hostess and the user in order to provide good service at the restaurant and allow the user to reserve a table at the restaurant. The restaurant interacts with the host when the host gets the reservation from the user. The restaurant/manager will check the status of the restaurant and try to maintain good standards/service to the restaurant. Also, the restaurant/manager will frequently check with the host/hostess to check if there are any problems. Vise versa, the host will interact with the manager/restaurant if they are in need of help or a service. The user will either proceed to talk to the manager/restaurant if something is not correct, or the manager/ restaurant will walk by to ask if there is anything needed. The restaurant/manager also provides the user coupons, rewards to come back to the restaurant, in addition to information about the restaurant on the application.
Flow model: User
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the user as being the most important stakeholder in this diagram. The user is the stakeholder that interacts with the host/hostess and the restaurant/manager in order to get a reservation at a restaurant. The user in this diagram is either driving in the situation. From there the user is choosing what type food that they want, and maybe chooses restaurants that are nearby him/her using the application. The user then decides whom they want to dine with, and then reserves the party via the application. The application from the restaurant will notify and text the user when the table is ready. The user will interact with the host or the manager if the application fails to work. The host will then interact with the manager/restaurant if something is needed. The restaurant/manager will agree to the host’s requests and maintains good restaurant standard. Also, the manager/ restaurant will provide the user offers, and deals for the user to use in order to come back the restaurant through the application.
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the host/hostess as being the most important stakeholder in this diagram. The host/hostess is the stakeholder that interacts with the user and the restaurant/manager in order to provide a table for the user. The
user in this diagram is choosing what restaurant they want, what type of food they want, and then using the application to reserve a table. The hostess/host would receive a reservation request from the user right away and would be able to use the computer to access the user’s info for the table reservation. Hostess/host would then check the availability, and ensures that the table and such needs will be present when the user arrives and the service would automatically give the user an estimated time when their table would be ready. The host/hostess waits upon the user. The restaurant/manager would receive information from the host/hostess that reservation(s) have been made. The manager/restaurant checks the status of the restaurant and tells the host/ hostess any other information if there is a change in plans or something has happened. The hostess/host also tells the manager/restaurant if something goes wrong, or needs help. The restaurant/manager also provides the user information about the restaurant for the app. The user also interacts with the manager/restaurant if they are having poor service.
Flow model: The restaurant/manager
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the restaurant/manager as being the most important stakeholder in this diagram. The restaurant/manager is the stakeholder that interacts with the host/hostess and the user in order to provide good service at the restaurant and allow the user to reserve a table at the restaurant. The restaurant interacts with the host when the host gets the reservation from the user. The restaurant/manager will check the status of the restaurant and try to maintain good standards/service to the restaurant. Also, the restaurant/manager will frequently check with the host/hostess to check if there are any problems. Vise versa, the host will interact with the manager/restaurant if they are in need of help or a service. The user will either proceed to talk to the manager/restaurant if something is not correct, or the manager/ restaurant will walk by to ask if there is anything needed. The restaurant/manager also provides the user coupons, rewards to come back to the restaurant, in addition to information about the restaurant on the application.
Flow model: User
This flow model shows the interaction with the restaurant, the user and the host/hostess. This specific diagram is identifying the user as being the most important stakeholder in this diagram. The user is the stakeholder that interacts with the host/hostess and the restaurant/manager in order to get a reservation at a restaurant. The user in this diagram is either driving in the situation. From there the user is choosing what type food that they want, and maybe chooses restaurants that are nearby him/her using the application. The user then decides whom they want to dine with, and then reserves the party via the application. The application from the restaurant will notify and text the user when the table is ready. The user will interact with the host or the manager if the application fails to work. The host will then interact with the manager/restaurant if something is needed. The restaurant/manager will agree to the host’s requests and maintains good restaurant standard. Also, the manager/ restaurant will provide the user offers, and deals for the user to use in order to come back the restaurant through the application.
Reasons for Modifications:
Host/Hostess:
Changes are italicized. These changes were done in order to include the application in the model. The model before did not have it and now it more specifies how the flow communication would change with the use
of the application. The flow model now includes how the application would affect the hostess, the user and the manager of the restaurant. Also, the interviews helped shape how these models would look with the application present.
User:
The changes are italicized and the diagram now includes the application. These changes were done in order for everything to be consistent with the application present. Also, with the help of the second interview, more
insight was giving on how the user would use the application if they had it available. This better shows the
communication with the hostess the user and the manager with the application.
Changes are italicized. These changes were done in order to include the application in the model. The model before did not have it and now it more specifies how the flow communication would change with the use
of the application. The flow model now includes how the application would affect the hostess, the user and the manager of the restaurant. Also, the interviews helped shape how these models would look with the application present.
User:
The changes are italicized and the diagram now includes the application. These changes were done in order for everything to be consistent with the application present. Also, with the help of the second interview, more
insight was giving on how the user would use the application if they had it available. This better shows the
communication with the hostess the user and the manager with the application.
Sequence Models
Sequence Model Explanations
These models are step by step description of what generally would occur if restaurants today used our application along with their current business practices. There is a model of the general steps a person would take leading up to eating at a restaurant, A model of the normal steps that a hostess makes during a day at work using our application, and the last model is a model of the potential business practices of a restaurant manager utilizing our application.
In the user sequence model, it explains in the steps that two people would very commonly take leading up to eating at a restaurant and using our application to do so. It begins with them deciding as they are outside, that they would like to eat at a nearby restaurant, and it progresses from there, to trying to decide where to eat, and then to using APPetite to help them decide. The app gives them several options, which they narrow down based on what they
would both like to eat. The scenario ends with them narrowing their choice down to two restaurants, and deciding to go to the one that APPetite told them had a shorter wait time.
In the hostess sequence model, it describes the sequence of events that a hostess would likely incur starting from the beginning of her shift, which would most likely be a slow period in a restaurant’s day, to the end, which would likely be a much busier time of the restaurant’s day. At the beginning the hostess comes to her desk, and has few customers, some of which are walk ins, and others who have already notified the restaurant that they will be coming through APPetite. As they come in, tables are readily available, and seating the customers as they come in is quite simple. As her day progresses, tables become more and more scarce. By the time she reaches prime hours, there are many more people coming in than they can accommodate at once, and she puts new walk-ins on the waiting list, and people who put themselves on the waitlist via the application are automatically put on the wait list in real time. The application also notifies party’s as their tables become available.
In the restaurant sequence model, it describes a restaurant that is fairly new, going about business in a normal fashion. It then transitions to the restaurant owner trying to increase revenue by attracting customers. The restaurant owner then finds out about APPetite, and decides it would be a very effective and inexpensive method of advertisement. The company purchases the software, and quickly becomes more noticed and more popular. The scenario ends with the restaurant as a result of using the app becoming much more successful.
In the user sequence model, it explains in the steps that two people would very commonly take leading up to eating at a restaurant and using our application to do so. It begins with them deciding as they are outside, that they would like to eat at a nearby restaurant, and it progresses from there, to trying to decide where to eat, and then to using APPetite to help them decide. The app gives them several options, which they narrow down based on what they
would both like to eat. The scenario ends with them narrowing their choice down to two restaurants, and deciding to go to the one that APPetite told them had a shorter wait time.
In the hostess sequence model, it describes the sequence of events that a hostess would likely incur starting from the beginning of her shift, which would most likely be a slow period in a restaurant’s day, to the end, which would likely be a much busier time of the restaurant’s day. At the beginning the hostess comes to her desk, and has few customers, some of which are walk ins, and others who have already notified the restaurant that they will be coming through APPetite. As they come in, tables are readily available, and seating the customers as they come in is quite simple. As her day progresses, tables become more and more scarce. By the time she reaches prime hours, there are many more people coming in than they can accommodate at once, and she puts new walk-ins on the waiting list, and people who put themselves on the waitlist via the application are automatically put on the wait list in real time. The application also notifies party’s as their tables become available.
In the restaurant sequence model, it describes a restaurant that is fairly new, going about business in a normal fashion. It then transitions to the restaurant owner trying to increase revenue by attracting customers. The restaurant owner then finds out about APPetite, and decides it would be a very effective and inexpensive method of advertisement. The company purchases the software, and quickly becomes more noticed and more popular. The scenario ends with the restaurant as a result of using the app becoming much more successful.
Reasons for Modifactions:
The models were not changed because they accurately portrayed the use of the application. After showing our stakeholders our models, they agreed that the sequence models represented excellent use of the application. Each diagram showed interaction with the other stakeholders.
Cultural Models
Cultural Model Explanations
User:
The cultural user model represents how social norms and needs will affect the way in which the user uses the App. In the cultural model the user interacts with three other entities: co-diners, app culture, and the restaurant culture. In this representation, the user is the individual who will select a restaurant that meets the needs of the dining party. The dining party wants the user to select the best restaurant that has the shortest wait time. The user in turn wants to succeed at this task and be recognized by the group. In relating to the restaurant culture, the user desires a quality dining experience that meets the needs of them and their group. These needs can be related to atmosphere, cuisine, service time, etc. The needs of both the user and their co-diners can be met more effectively through the use of the App. The user will likely stop using the App should it fail to meet their needs, even if it only fails on one occasion. This would be due to the user attempting to avoid negative cultural pressure from the dining group. The app culture in turn wants the user to use their app frequently, to promote its popularity, and assist in providing feedback for marketing research.
Hostess:
The cultural hostess model represents how social norms and needs will affect the way in which the hostess uses the App. In the cultural model the hostess interacts with four other entities: the restaurant, co-workers, app culture,
and customer culture. The restaurant wants the hostess to seat all customers possible while being courteous and helpful. The hostess in turn wants the restaurant to provide assistance in their tasks through various tools, including
the App, and help with customers who take issue with the process. The hostess sometimes has to deal with these types of customers who complain about the wait. They want the customers to be orderly and courteous in return for their friendly service. In order to lessen the wait time and avoid the customers becoming impatient, the hostess wants the other staff, i.e. servers and bussers, to move customers along and clear tables more quickly. The staff does not
want to do this if they are understaffed and very busy. They instead want the hostess to try to slow the amount of incoming guests. The hostess potentially has incentive to misuse the App. Although the App will lessen wait times for
customers and therefore lessen the frequency of them becoming annoyed, the hostess may still receive pressure from the other staff to not update table availabilities in a timely manner in an attempt to slow customer traffic. The hostess is also concerned about the reliability of the App, and does not value something that could potentially make her job more difficult. The app culture wants the hostess to use the App correctly and troubleshoot any problems to ensure
proper service.
Restaurant:
The cultural restaurant model represents how social norms and needs will affect the way in which the restaurant uses the App. In the cultural model the restaurant interacts with four other entities: employees, customer culture,
app culture, and the restaurant owner. The restaurant is tasked by the owner with being more profitable. To accomplish this, the restaurant requests better tools to improve customer service, including the App, from the owner. Also, to improve profitability, the restaurant requests that the employees provide better service in order to attract
more customers. The employees desire more benefits to increase their performance; however this might result in lower profitability. Finally, to improve profitability, the restaurant wants the customer culture to develop an affinity for their restaurant and be willing to eat there more often and pay higher prices. The restaurant has a need to be hands on with the App functions. There is a need for oversight of the hostess’ updates, and a desire to use the App to improve customer loyalty through benefit programs.
The cultural user model represents how social norms and needs will affect the way in which the user uses the App. In the cultural model the user interacts with three other entities: co-diners, app culture, and the restaurant culture. In this representation, the user is the individual who will select a restaurant that meets the needs of the dining party. The dining party wants the user to select the best restaurant that has the shortest wait time. The user in turn wants to succeed at this task and be recognized by the group. In relating to the restaurant culture, the user desires a quality dining experience that meets the needs of them and their group. These needs can be related to atmosphere, cuisine, service time, etc. The needs of both the user and their co-diners can be met more effectively through the use of the App. The user will likely stop using the App should it fail to meet their needs, even if it only fails on one occasion. This would be due to the user attempting to avoid negative cultural pressure from the dining group. The app culture in turn wants the user to use their app frequently, to promote its popularity, and assist in providing feedback for marketing research.
Hostess:
The cultural hostess model represents how social norms and needs will affect the way in which the hostess uses the App. In the cultural model the hostess interacts with four other entities: the restaurant, co-workers, app culture,
and customer culture. The restaurant wants the hostess to seat all customers possible while being courteous and helpful. The hostess in turn wants the restaurant to provide assistance in their tasks through various tools, including
the App, and help with customers who take issue with the process. The hostess sometimes has to deal with these types of customers who complain about the wait. They want the customers to be orderly and courteous in return for their friendly service. In order to lessen the wait time and avoid the customers becoming impatient, the hostess wants the other staff, i.e. servers and bussers, to move customers along and clear tables more quickly. The staff does not
want to do this if they are understaffed and very busy. They instead want the hostess to try to slow the amount of incoming guests. The hostess potentially has incentive to misuse the App. Although the App will lessen wait times for
customers and therefore lessen the frequency of them becoming annoyed, the hostess may still receive pressure from the other staff to not update table availabilities in a timely manner in an attempt to slow customer traffic. The hostess is also concerned about the reliability of the App, and does not value something that could potentially make her job more difficult. The app culture wants the hostess to use the App correctly and troubleshoot any problems to ensure
proper service.
Restaurant:
The cultural restaurant model represents how social norms and needs will affect the way in which the restaurant uses the App. In the cultural model the restaurant interacts with four other entities: employees, customer culture,
app culture, and the restaurant owner. The restaurant is tasked by the owner with being more profitable. To accomplish this, the restaurant requests better tools to improve customer service, including the App, from the owner. Also, to improve profitability, the restaurant requests that the employees provide better service in order to attract
more customers. The employees desire more benefits to increase their performance; however this might result in lower profitability. Finally, to improve profitability, the restaurant wants the customer culture to develop an affinity for their restaurant and be willing to eat there more often and pay higher prices. The restaurant has a need to be hands on with the App functions. There is a need for oversight of the hostess’ updates, and a desire to use the App to improve customer loyalty through benefit programs.
Reasons for Modifications:
User:
The User cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and projected cultural dynamics.
Host/ Hostess;
The Hostess cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and projected cultural dynamics.
Restaurant:
The Restaurant cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and
projected cultural dynamics.
The User cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and projected cultural dynamics.
Host/ Hostess;
The Hostess cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and projected cultural dynamics.
Restaurant:
The Restaurant cultural model was updated to add the future cultural conditions in which the App will be used. Additional information was received via the follow-up stakeholder interview which was relevant to the current and
projected cultural dynamics.
Artifact Model
Reasons for Modification:
The models were not changed because they accurately portrayed the use of the application. After showing our stakeholders our models, they agreed that the sequence models represented excellent use of the application. Each diagram showed the application in use, such as it being present in the restaurant with the hostess using the application.
Artifact Model Explanations
User Artefact Model Explanation
This model shows the user using APPetite within the proximity of a restaurant whilst walking. The
only other time the app would display available restaurants is if the user selected the “I am driving” option in the app. If out of range from restaurants, the app will not show any restaurants on the area. The options that a user could select are shown and described in the mock-up documentation. This model shows a user walking towards a restaurant. The user may select the restaurant from the map. From there, they will be able to view the restaurant’s menu and make areservation from there. The user would then be told the projected wait time and approximately what time they
would be seated. The user would also receive a notification alert when their table was ready, just as a buzzer from the restaurant would. The app allows the user to theoretically“wait in line” without ever actually waiting in line, which would reduce the crowding in the restaurant. Because the customer would be alerted via the app, the alert would be sent over the carrier network, and therefore, range from the restaurant would not matter. Therefore, if the user has an hour long wait time, they would be able to visit other points of interest within the area without fear of losing signal from the restaurant. This makes things tremendously faster for the customer and restaurant. Because the menu is available on the app, the user may already decide what they want upon entering, they would not have to wait to be seated, theoretically, and they would be able to instantly place their order without having to wait. This is beneficial for both the customer, who may be on a time restraint, and for the restaurant as it would allow for a faster flow of customers.
Host/Hostess Artefact Model Explanation
The first graphic in this model shows a potential workplace for a hostess at a restaurant. In front of the
hostess is a computer, a telephone, a few buzzers, and a menu holder. The telephone is used primarily to
communicate with other areas of the restaurant. The buzzers are used to alert customers when their table is ready. This is something that our app, APPetite, would help with. The buzzers could be limited in number, may be easily breakable, could get misplaced or stolen, and the restaurant would have to pay to replace the buzzer. APPetite would serve as the buzzer for customers using the app. Of course, not everyone has a smartphone capable of running the
application, so buzzers would remain a mainstay in the dining business, but with the increased use of smartphones, the use of buzzers would decrease, thus lowering the cost to the restaurant. The hostess also has a menu holder that holds menus that will be distributed to customers. Depending on the size of the restaurant chain and the frequency of menu change, APPetite could help restaurants decrease the amount of money and time spent on menus.
APPetite would include a menu for the restaurant selected, and the menu may be customised to suit the theme of the restaurant. This would allow restaurants to decrease the amount of money spent on paper menus as well as help the environment, along with reducing the amount of time on distributing new menus to restaurants. Finally, the hostess has in front of her the computer, which hosts two tabs, the Group List Tab and the Table Map tab. The table map tab would show the map of the restaurant’s tables, the number of customers at each table, at what time they were seated, and the waiter or waitress assigned to that table. The Group List Tab would show the list of customers both entered manually by the hostess, the customers that were added via APPetite, as well as options to add, delete, and modify a
group details. The groups will be listed in the order they were added to the system, either by the hostess or APPetite. The hostess will see the time the reservation was added, the group name, the number of guests in the group, as well as their projected wait time.
Manager Artefact Model Explanation
The manager side of the APPetite application shows not only the same details that the host/hostess would see, but includes functions for auditing purposes, for example, when dealing with customer complaints, staff improvement, or other purposes. The manager would be able to see not only the list of customers, but the amount of time they actually waited, determined by the hostess confirming that the group has arrived, as well as the waiter or waitress that helped the group. The manager also has a telephone that would be used for communication not just throughout the restaurant, but externally as well. The manager also has the ability to perform the same functions that a regular host or hostess would be able to perform, such as adding, deleting, or modifying a group’s details. The APPetite app is designed to encompass most of restaurant management, from the table management, to creating reservations, and improve customer flow, which is something that a manager would also be able to see. The APPetite restaurant side would also include a list of the customers that requested a table via the app as well as walk in customers.
This model shows the user using APPetite within the proximity of a restaurant whilst walking. The
only other time the app would display available restaurants is if the user selected the “I am driving” option in the app. If out of range from restaurants, the app will not show any restaurants on the area. The options that a user could select are shown and described in the mock-up documentation. This model shows a user walking towards a restaurant. The user may select the restaurant from the map. From there, they will be able to view the restaurant’s menu and make areservation from there. The user would then be told the projected wait time and approximately what time they
would be seated. The user would also receive a notification alert when their table was ready, just as a buzzer from the restaurant would. The app allows the user to theoretically“wait in line” without ever actually waiting in line, which would reduce the crowding in the restaurant. Because the customer would be alerted via the app, the alert would be sent over the carrier network, and therefore, range from the restaurant would not matter. Therefore, if the user has an hour long wait time, they would be able to visit other points of interest within the area without fear of losing signal from the restaurant. This makes things tremendously faster for the customer and restaurant. Because the menu is available on the app, the user may already decide what they want upon entering, they would not have to wait to be seated, theoretically, and they would be able to instantly place their order without having to wait. This is beneficial for both the customer, who may be on a time restraint, and for the restaurant as it would allow for a faster flow of customers.
Host/Hostess Artefact Model Explanation
The first graphic in this model shows a potential workplace for a hostess at a restaurant. In front of the
hostess is a computer, a telephone, a few buzzers, and a menu holder. The telephone is used primarily to
communicate with other areas of the restaurant. The buzzers are used to alert customers when their table is ready. This is something that our app, APPetite, would help with. The buzzers could be limited in number, may be easily breakable, could get misplaced or stolen, and the restaurant would have to pay to replace the buzzer. APPetite would serve as the buzzer for customers using the app. Of course, not everyone has a smartphone capable of running the
application, so buzzers would remain a mainstay in the dining business, but with the increased use of smartphones, the use of buzzers would decrease, thus lowering the cost to the restaurant. The hostess also has a menu holder that holds menus that will be distributed to customers. Depending on the size of the restaurant chain and the frequency of menu change, APPetite could help restaurants decrease the amount of money and time spent on menus.
APPetite would include a menu for the restaurant selected, and the menu may be customised to suit the theme of the restaurant. This would allow restaurants to decrease the amount of money spent on paper menus as well as help the environment, along with reducing the amount of time on distributing new menus to restaurants. Finally, the hostess has in front of her the computer, which hosts two tabs, the Group List Tab and the Table Map tab. The table map tab would show the map of the restaurant’s tables, the number of customers at each table, at what time they were seated, and the waiter or waitress assigned to that table. The Group List Tab would show the list of customers both entered manually by the hostess, the customers that were added via APPetite, as well as options to add, delete, and modify a
group details. The groups will be listed in the order they were added to the system, either by the hostess or APPetite. The hostess will see the time the reservation was added, the group name, the number of guests in the group, as well as their projected wait time.
Manager Artefact Model Explanation
The manager side of the APPetite application shows not only the same details that the host/hostess would see, but includes functions for auditing purposes, for example, when dealing with customer complaints, staff improvement, or other purposes. The manager would be able to see not only the list of customers, but the amount of time they actually waited, determined by the hostess confirming that the group has arrived, as well as the waiter or waitress that helped the group. The manager also has a telephone that would be used for communication not just throughout the restaurant, but externally as well. The manager also has the ability to perform the same functions that a regular host or hostess would be able to perform, such as adding, deleting, or modifying a group’s details. The APPetite app is designed to encompass most of restaurant management, from the table management, to creating reservations, and improve customer flow, which is something that a manager would also be able to see. The APPetite restaurant side would also include a list of the customers that requested a table via the app as well as walk in customers.
Reasons For Modification:
The models were not changed because they accurately portrayed the use of the application. After showing our stakeholders our models, they agreed that the sequence models represented excellent use of the application. Each diagram showed the application in use, such as it being present in the restaurant with the hostess using the application.