The first question I would ask about a digital product

If I had a new digital product idea, I would first look for one question that needs an answer. Something whose answer would change what we build next.

For example: can someone find the approved video version without asking a colleague? That is specific enough to make a small prototype and observe what happens.

One situation from a workflow

Imagine a team with three video versions and comments spread across several conversations. Before publication, someone tries to work out which file is approved.

My idea would be to show the version, status and approver in one place. The assumption is that this would let someone find the right file independently.

Before making screens, I would speak with a few people who do this work. I would ask about the last time they looked for a final version. Where did they look? What was unclear? How did they decide which file to use? This is a fictional example; in a real conversation, I would want their specific situation.

Enough prototype to answer the question

Here, one project, three versions, comments and an approval would be enough. Connected screens or a simple HTML page could do the job.

The links and statuses needed for this task would have to work. Payments and other features could wait. At this stage, I want to know whether the approval is understandable.

I would give the user this task:

You need to prepare a video for publication.
The project has three versions and several comments.
Find the file that can be published now.
Show who approved it and where you can verify that.
If information is missing, explain what you need.

I would avoid explaining what to click at the start. If someone stops, I would record where and what they ask. I would also record any help I gave, so I can see what they completed independently.

There is more about designing tasks and observing participants in the GOV.UK usability testing guide.

What could this tell us?

For a first attempt, we could invite five people familiar with this work. With such a small group, I would look for specific points of confusion rather than draw conclusions about the entire audience.

I would record which version each person chooses, how they explain the choice and whether they need help. I would also want to know how they currently do the same job.

We could agree that at least four out of five must find the right file without help. That would be a criterion for this test. I would also examine even one selection of an unapproved file closely: in publication, it could be a significant mistake.

If people confuse the version with its status, we revise the display and try again. If everything is clear but this problem rarely occurs in their work, we need to reconsider the need itself.

Completing the task still does not tell us whether the team will change habits or pay for the product. The next step could be a small trial in a real project: do people return to it when we are not there?

I would like to finish this stage with one page: what we wanted to test, what we saw and what we will do next. It would give the next version a clearer starting point.