Hi – designing a voice recording app where there needs to be some data captured eventually. Stuff like who is recording, who is talking, what is the topic.
Is there any consensus around whether it feels better to do this kind of work chunked, up-front, before your main task? Or push it to the back and do something like require it on save?
Obviously, I’m trying to require as little as possible and only when absolutely necessary. But either way it still feels like work!
Depends on the workflow expected. If there's a really consistent expectation among the people using this specific app, then use that reference.
For example, if you're targeting people doing medical transcription's, and the industry standard is to collect metadata up-front (because that's what people in medical offices tend to do), then front-load the metadata. Pareto's Principle (80/20 rule) is a good rule of thumb when looking at this kind of pattern (even if not exactly what he had in mind). If 80% of of the users interviewed front-load work, then it's probably a good idea to design the application to match this expectation.
However, if the split is not as well defined (e.g., 60/40) or you're targeting a broader audience, then it's better to offer some flexibility. For example, if the target of the app is salespeople recording information about a meeting, then it might be better to allow BOTH front-loading or back-loading information to afford different situations and work methods. In one instance, it might be better to quickly record the information while it's fresh after leaving the meeting, then go back and add metadata after getting to the hotel. Other instances, it may be easier to preload the metadata before the sales meeting in the first place (meaning you have a metadata record with NO recording for some period of time). Both are valid ways to work, so long as required information is collected before reaching the next step in the workflow.
Generally, I try to accommodate flexibility in these kinds of workflows so long as it doesn't introduce more complex mental models or UI. In the past, I've even developed secondary workflows that would automatically trigger on condition to ask for missing metadata after the fact. So, the flow might look something like this...
Lastly, be sure to consider time in the workflow. As a couple of these examples have hinted, saving drafts frequently and automatically is probably a good idea. Furthermore, even if the metadata is ultimately required, look at WHEN the metadata is consumed in the larger workflow. It's easier to make a field required for a DB, but people are typically a bit more complicated and sloppy in processes.
Longer answer than I intended, but you should consider the situations and stakeholders specific to your needs. Without context, I'd suggest trying to allow both adding metadata before and after the recording. Even by creating several "empty" recordings that just have metadata, or having several recordings with partial or missing metadata that need to be completed before whatever happens next.
I'd suggest to chunk this into two steps.
The first step is the recording. The UI is just displaying the record, pause, and stop buttons.
After stopping the recording, the second step on the next screen apears. Here you can add all the meta stuff such as title, description and so on.
Why?
It is not uncommon that you get new ideas about what you'd like to talk about while you're recording. If the recording is the second step, you alway need to go back to the first step to change the description in this case.
Now you can do all the recordings first and then describe what you've talked about. Just a clean experience.
If you don't split the recording and the meta stuff into two steps, you may loose the focus and get a bad expirience due to scrolling and complexity.
See the instagram workflow for creating a new post. Even the focus is about pictures instead of recordings, they're doing very great and have proved this workflow as good ux.
