I'm developing a mobile application which function is basically to let the user fill in forms. What forms and how many different forms varies per user.

Obviously, the primary function of the app is to let the user create a new registration of a form. (Just to be clear: registrations are made when the user fills in form and saves the data) For this functionality it seems obvious to use workflow similar to the one below.

UI for creating registrations

The secondary function of the app is to let the user view all previous registrations of a form. However, an admin can choose to disable this functionality for a certain form (for instance due to privacy concerns). Only considering this function a workflow like the one below seems most obvious. UI for searching registrations

As you've probably noticed the first screen of the first flow is pretty much the same as the first flow in the second flow. What do you think would be the best solution for combining these screens? Please feel free to disregard the UI shown above if you have a better solution!


There are reasons why this may not be a good solution, which I list, below:

Combining both workflows

This solution may break an OS rule, which suggests you should look for a different way to solve this. This solution presumes that people who fill in new registration forms also need and want to see the existing registrations, and that seeing the existing registrations is the more important of these two tasks. If not, then switch the middle screen and the upper screen, but leave the button on the middle screen and rename it from New to See all or some such.

I can't say I'm enthusiastic about this solution. I'm not the only one who questions the iOS standard for the Done button. Be sure to test it with a half-dozen target users who have scenarios that involve both tasks.

  • 1
    This makes a lot of sense to me. I'm not sure what OS navigation rules you may potentially be breaking by putting in a "Create New" button on a List View page. Can you elaborate? BTW - Button in the top right corner is an iOS convention. Android's Material Design has the floating action button on the bottom right. – nightning Oct 26 '15 at 20:34
  • Exactly, the Done button wouldn't always go in the top-right corner, and might not always be named Done. With these generic Balsamiq illustrations, it's never clear which OS is being illustrated. Also, I haven't illustrated the flow with the hardware's Back button, or the top-right button. These are all OS-specific details to consider. I think developers sometimes want one approach for every platform, which is like expecting users to go to McDonald's to eat a Whopper. :o – JeromeR Oct 27 '15 at 4:19

Perhaps you could combine the two pages into a nested/expanding view to show the hierarchy, like this:

enter image description here

  • Thanks for your answer! I'm sorry but it appears I should've been more clear on what I'm looking for. I want to combine screen #1 from the first flow and screen #1 from the second flow. So one list of forms in which each item/form has a primary action of "create new registration" and optionally a secondary action of "search registrations". – user3017745 Oct 23 '15 at 20:02

We had a similar concern in our app. We added a hamburger menu on the left side of each record to expose commonly used action buttons.

Flow #1: tap action menu (overlay buttons appear), tap Add Registration button

Flow #2: tap list item, list of historical registrations appears.

enter image description here

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.