When Does "What" Become the "How"?
As a product owner, I find myself deeply involved in writing acceptance criteria. Sometimes when writing, I wonder if I'm being too prescriptive. For instance, if I write an AC that says to add a button to perform some action, am I getting too much into the "how" by saying it needs to be a button? Can this reduce the creativity and efficiency of the development team? When does the "what" start creeping into the "how"?
It depends on your perspective.
Let's take the example of creating an online store or marketplace.
The user - a customer - has an objective of finding items that the market is selling. This is the first level of "what". As a Product Owner, you use your knowledge, experience, and talking to customers to figure out different ways for "how" customers complete this objective - searching, browsing, seeing related items.
However, to a UX designer, these are all "what"s. How a user searches, browses, or finds related items is still to be designed. A UX designer can come up with lots of ways for a user to do each of these. Just taking one example of searching, the UX designer would get into "how" - text and icons to indicate that searching is available, the placement and sizing of search boxes, if there are search suggestions as the person types, how the results are presented to the person searching. There are different levels of fidelity for capturing these.
To a developer, these are all still "what". At a technical level, there are architectural choices for how to implement search, what UI frameworks to use, how to ensure performance. These are the "how"s.
Depending on your organization, your levels may look different. Perhaps you do UX design and development at the same time, so you don't want to get into the idea of a button. Maybe you don't have a separate UX designer or researcher and you know that a button is the right answer. Perhaps, as the Product Owner, you know that a button is the correct answer.
I don't think there are any good rules of thumb for how much to constrain the work of the downstream step. It depends a lot on the context in which you are working and what your workflow to go from idea to delivery looks like.
if I write an AC that says to add a button to perform some action, am I getting too much into the "how" by saying it needs to be a button?
Is the presence of a button essential to the valuable outcome you seek as Product Owner? Does the use of a specific control increase value? If so, why?
@Adam, if you are not sure, you can involve the team (as the 'conversation' in the 3C's or the Negotiation in INVEST suggests) or simply say that it is 'specification by example' where only the desired outcome is fixed. It also depends on the people involved, some devs are quite autonomous, others prefer to use your brain.