Kindred Hands was intended to help weavers sell more directly to customers without our taking commission. My technical responsibilities included the e-commerce and multi-vendor side of the initiative, with support. That made the route after a product page part of my responsibility too. A photograph and a button could not explain the whole service.
I’m following an order here, with a sample product and no real buyer, payment or delivery attached to it. The example lets me separate the jobs instead of treating one click as a complete transaction. The purpose is straightforward: someone should understand what they are asking for, and the people handling it should understand what they need to do next. Once I try to explain that in order, the apparently small task begins asking much more useful questions.
First, there is a person interested in a product. What tells them it is available? A page can remain visible after the product has been sold elsewhere. Availability needs to stay in step with the product. It tells me that “available” must come from somewhere, and someone must be responsible for changing it. The product photograph by itself cannot answer the question.
Next comes the request. I’m deliberately calling it a request in this example because I should not assume that clicking something means a payment has been made or an order has been accepted. Those are separate events. If the process requires someone to check availability first, the person making the request should understand that. Otherwise the software could give them more confidence than the organisation can support at that stage.
Now I reach the first question that is easy to hide behind the word “system”: who gets told? The seller, the person managing the site, someone assisting with listings, or more than one of them? A message going somewhere is only useful if somebody knows they are supposed to act on it. Sending it to everyone might create the opposite problem, with each person assuming someone else is handling it.
Imagine that the supplier needs to answer a question about the product before anything continues. I want that step to be visible in the route. The buyer should not have to guess whether silence means nobody saw the request or somebody is checking it. The administrator should not have to remember the whole situation from a conversation that is not connected to the product.
Payment adds another set of questions. Who is expected to collect it? When would the supplier be told what amount to expect? Are there charges, shipping costs or other deductions that need to be explained? I don’t have to put figures into the example to recognise that the final amount should mean the same thing to the people involved. A price shown to a buyer and a receipt for a supplier can describe different amounts for perfectly ordinary reasons. Those reasons should not disappear between screens.
Delivery is not something the website can wish into existence either. Somebody has to pack the product and arrange for it to reach the buyer. If a person updates the status, what are they actually saying has happened? “Ready” and “sent” are different claims. A process that uses those words loosely could look active while leaving everyone with a different understanding of where the saree is.
I also want an ending for the order that is not successful. In this case, the product is unavailable before the request is confirmed. What does the buyer hear? Who closes the request? If I only draw the happy path, I will make the process seem much simpler than it is. The unhappy path does not need to be dramatic. Even a clear explanation that something cannot go ahead is part of a usable service.
The exercise is making the roles more important than the number of screens. One person might handle several steps in a small organisation. That can be completely reasonable. What would be confusing is leaving the role unnamed because the same person happens to be around at the start. If the arrangement depends on somebody noticing everything without being told, I have not really described the arrangement yet.
There’s a technical question underneath each ordinary step. Where does the request get recorded? What connects it to the correct product? What information does the next person see? Those are better questions for my mentor than asking whether a marketplace tool is complete. We can follow one route, find an assumption and decide whether the software or the working routine needs attention.
There’s a useful difference between recording a state and explaining it. In the route, a record might say that a request is waiting. Waiting for what? The buyer may be waiting for confirmation, while the administrator is waiting for a detail from the supplier. One short label could be technically correct and still leave each person uncertain. I want the process to explain enough of the reason that they know whether they need to act.
I’m also noticing that information can become less useful by arriving too late. If somebody needs to confirm availability, learning about the request after everyone assumed it was accepted creates a problem that no attractive product page can fix. I’m recognising that the route includes time as well as steps. A process can be correct on paper and still be difficult if nobody understands when the next person should take over.
That gives me another way to examine an option. I can ask whether it helps people notice and understand the next task, rather than only whether it stores the information somewhere.
By the end of this walkthrough, the order has done something useful without becoming a sale. It has exposed the places where I was writing “someone handles it” in my head. I want the people using Kindred Hands to know what happens next. That begins with me being able to explain it all the way through, including the part after the page stops looking interesting.