Best way to organize process of adding child records to a parent record from a UX perspective

Question

I'm working on a browser-based DBMS application, and I'm running into some complications around the best way to handle user navigation while creating records.

Viewing and editing records seems pretty straightforward; I have three use cases (with one extension):

1. View all records in an entity
2. View one record in detail
3. Edit one record, may include adding child records

Navigation through these is linear: the user views all the records, picks one, edits it (or doesn't), saves edits (or doesn't) and navigates back the way he came.

When creating a new record, navigation appears less straightforward. For this use case (extended by an optional "Add child records" use case) there are more navigation scenarios that seem reasonable:

1. User cancels and goes back to what he was doing.
2. User saves and goes back to what he was doing.
3. User saves and creates another record of the same type.
4. User saves and continues to the add child records extension.

(I've ruled out allowing adding of child records to an unsaved record, i.e. while still in the create context.)

Of these, I'm struggling with a UX issue for scenario 4. The essential issue is that the user is technically in the edit context once he saves the record, but functionally is continuing the creation of the record.

I see three possible options:

1. Upon saving, send the user to the edit context for the saved record (use case 3).
2. Upon saving, send the user to the view context for the saved record. Move the add child records extension use case from edit to view (use case 3 to use case 2).
3. Upon saving, give the user the option of adding child records, and if so, go to a specific implementation of the use case.

Option 1 has drawbacks. If the user saves the new record and then goes to edit mode just to add child records, he also will have to save the parent record or cancel, which is poor design. So, not my favorite.

Option 2 is the one I'm leaning towards. I would change the edit context to just editing the parent record, rather than also being the place to add child records. This would also require repurposing the view context, since editing isn't viewing. Perhaps the current view context might be a "Grand Central" for a given record, from which you could do any sort of editing of that record.

Option 3 is another possibility, which would require more development work and might become a more complex way to handle the need than option 2. Not sure if I want to go that way.

So. How can I best accomplish this in a consistent and intuitive manner? Please share ideas and questions, and thanks for reading.

Answer 1

If you want to know the best solution from a user experience perspective, create mock-ups of a couple of those options and test them with a few people (you can use simple mock-ups to test design ideas) - you don't need to test with many people, and you will soon see which option one works best.

I only say this because I work with Enterprise software and it is the only way to work out which design works best for the people who will be using this solution day in/day out. You certainly don't want to piss them off by providing a solution which does not work effectively or efficiently.

The other advice I would give you is to keep things simple to start with (KISS principle). Get the core part of your solution working perfectly first, then you can always add further features later in your roadmap if they are truly needed. If you try to do all those use cases you might end up running out of time an compromising the core part.

Answer 2

I would say your option 3 is better. In option 2 you are again pushing user to edit same record which is frustrating and bad UX for user.