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!

6 Answers 6


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, 2015 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, 2015 at 4:19

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


Split Buttons

A split button is a button with two components: a label and an arrow; clicking on the label selects a default action, and clicking on the arrow opens up a list of other possible actions.


  • Visually Separate Arrow Button

enter image description here

  • Use Text Labels for Split Buttons

enter image description here

Source and + info: nngroup.com

How to make a split button tutorial at w3schools.com

  • Problem here is that the label already holds the name of the item. No room for additional CTA.
    – JNF
    Mar 3, 2022 at 7:07

Take a step back in your user flow. Is your user really filling out Form 1, then Form 2, then Form 3, etc.?

Or are they reading information about Event 1, optionally seeing who else has registered, and then signing up?

It almost seems possible that two personas are being combined here - the individual registrant, and another persona who needs to keep track of who has registered for each event (like an administrator). If that's the case, you might want to map out what steps each persona is taking in a workflow, and what they need for each step. That should help make things more clear.

Design for what each persona needs to be doing, not for what an engineering team is building.


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".
    – JSAM
    Oct 23, 2015 at 20:02

For the most part, I think JeromeR's solution is the most typical way to solve this for iOS (although a little more awkward to design if users aren't permitted to see the list of past submissions).

Having said that, there are a few native examples of a table view row having two actions in iOS. Typically it's an info accessory button to perform a tangential action. Here's an example from Mail (the info button on the VIP mailbox edits the VIP list, but clicking anywhere else opens the mailbox contents):

A screenshot of iOS Mail, showing an info button for editing the VIP mailbox
Image from AppleInsider

A similar design is also used in the Phone app for recents and favourites, where clicking the info button views details about the entry but tapping anywhere else on the table row initiates a call:

A screenshot of the iOS Phone app's Recents view, showing info buttons for each item
Image from iDownloadBlog

If that doesn't work for you, it might be worth asking yourself why you want to merge these two screens at all; after all, users who are looking to complete a form are performing a meaningfully different task than users looking to review submissions. One option would therefore be to add a tab bar at the bottom of the screen to specifically split between listing/completing forms and reviewing submissions.

That would allow you to handle the design of the list of forms for creating and reviewing submissions differently (e.g. when listing forms to review submissions, you could conceivably add an "All submissions" option at the top for showing submissions for any form, and/or you could add a subtitle on each form showing the total number of submissions for that form).

  • Looks interesting, thanks
    – JNF
    Mar 9, 2022 at 5:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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