Conversation with the Client

First Conversation with the Client

Today marks the beginning of a new project. As always in such cases, there is a hint of excitement in the team, as well as attempts to guess what the project will be about. We have some information, but nothing is certain yet.

The conversation with the client begins. After a few minutes of preliminary discussion, we move on to specifics. (C - Client, T - Team).

T: How could we define the vision of the project? A main, overarching idea that will guide it. What is its purpose? It’s important because this vision we define now will be the main determinant of the actions we take. It also defines the goal of the project itself. It motivates us to take action. It allows us to create the final vision.

C: I would like to create an online system that allows intelligent searching of cooking recipes.

T: An interesting idea and a well-defined vision. Can we take a closer look at it?

C: Of course. There are many sites with cooking recipes, even very good ones. However, they have some drawbacks. They are quite static - they don’t allow more advanced searching of recipes. Usually, you can’t choose recipes based on personal preferences or search them based on the ingredients you have. There’s a lack of intelligence that would simplify life for users of the portal.

T: I’m slowly starting to get it. Maybe we should try to identify the key features of the system?

C: I have lots of ideas, but a small budget. Therefore, initially, I want to have the possibility to search recipes based on a list of ingredients I have at a given moment. Let’s say it’s Wednesday evening, I have eggs, flour, eggplant, milk, a bit of butter, and I want to make something with that. I have no idea what it could be. So, I go to the recipe search portal, enter the ingredients I have, and optionally preferences like type of dish – soup, cake, snack, type of cuisine – Polish, Asian, French, Italian… As a result, I get a few recipes that I can prepare with the ingredients I have. And that’s it.

T: And how will the user enter the data?

C: Everything must be as simple as possible from the user’s point of view. The user should think as little as possible and exert minimal effort. Therefore, I imagine there will be two text fields - one for entering ingredients, line by line, the second for entering preferences, which would be optional. Minimal input and configuration. Of course, there may be additional options, but available under the “Advanced” button. In the default form, it must be simplified to a minimum. There should probably also be some form of suggestion so that the user doesn’t have to type too much.

T: Interesting. How will the user enter ingredients in this text field? In what format? Maybe you could write an example on paper.

C: For example: 1/2 kg flour half a stick of butter 1/3 liter of milk 5 eggs

T: I must admit, this is quite a challenge. It will require analyzing this type of notation. Can’t we do it another way, e.g., through appropriate selection fields?

C: No, definitely not. Who would want to do it that way? It must be done like this. When I used the word “intelligent” in terms of vision, this is what I meant. I understand it will be quite labor-intensive.

T: Yes, very labor-intensive. But if it’s a necessary condition, we can of course implement it this way. We will later present an initial estimate of the problem’s complexity, and you can decide whether to proceed this way.

C: If I decide, it will only be this way!

T: So, I see the ingredients can be quite flexible – like kilograms written in full or abbreviated, even more conventional units like half a stick.

C: Yes, that’s also a necessary condition.

Well, it seems to be an unusual project - I think. It’s becoming more complex. I wonder what else our client will come up with.

T: Can anything else be entered in this field? Maybe in another form?

C: I don’t think so.

T: So what about the second field – Preferences? You also said it should be a text field.

C: Yes, definitely. Again here, I’d like the ability to freely enter preferences, e.g., soup, Asian cuisine.

T: So the elements would be separated by commas?

C: Yes, commas or a new line.

T: What type of preferences come to your mind?

C: Type of cuisine – region, type of dish – like soup, cake, possibly the type of diet it is allowed in, preparation time.

T: Can anything else be entered in this field?

C: I don’t think so.

T: Okay, so we have two text fields – in one we enter the ingredients available, in the other the preferences, and a search button.

C: Exactly! It should be like in typical internet search engines – a minimal but intelligent interface.

T: Okay, so let’s assume that the user enters the data and presses the search button. What happens next?

C: Then there is the results page! Just like a classic search engine. It would be good if the results list appeared in two forms: a condensed version – only the dish name and information related to preferences, like type of cuisine, type of dish; a detailed version – what’s in the condensed version plus the list of ingredients. In both cases, the dish name is a link to the page with recipe details.

T: Let me return to the mentioned lists for a moment – how will the user choose the type of list?

C: Hmm… By default, let it be the condensed version, but on the results list there will be a button to change the results form. Oh, and the results should be paginated like in a browser and ordered from best to weakest.

T: What will determine that one recipe is better than another?

C: Good question. Maybe it should be minimal or maximal product usage.

T: So what part of the products will be used?

C: Yes?

T: What will be the default option?

C: … Let it be minimal usage. And a button to change this sorting.

T: Great! Is there anything else that should be on this results page?

C: Probably not.

T: And you also mentioned the “Advanced” button…

C: Yes, but I don’t yet have an idea of what that should include. Well, one idea comes to mind. We could set a parameter that specifies which elements should not be considered. For example, salt and pepper, water, or other such items that everyone has, should not be entered. Therefore, the advanced settings could determine what is or is not considered.

T: How should that look? I think it would be a checklist where you could mark what is not considered.

C: And what could those be?

T: For now, what comes to mind is: water, salt, pepper, other spices. But this list could be extended.

C: Should anything else be in the advanced section?

T: Probably not.

Afterwards, we summarized the conversation and the key information that arose from it. We now have an outline of the requirements. It’s time to organize these requirements.

Tips for Conversations with Clients

A client can be anyone: a manager, a boss, a lecturer, a colleague, a representative of the customer. The beginning of a project is primarily a time to define the vision – declare what the system is for. This is the overarching goal of the project. We will base on it to determine with the client which actions make sense.

Next, we try to gather key requirements at a general level – what specific functions the system should perform. Once we have them, we break them down into finer details. Very useful are questions like:

• Is there anything else that should be included here…

• What is important next…

and questions that help move from general statements to specific ones:

• What specifically needs to happen/how does it need to work/how should it be organized to meet requirement X…

• What needs to be fulfilled to declare that the function has been implemented…

Of course, the scenario above is greatly simplified, but it gives some insight into how this type of conversation progresses.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)