Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am currently working on designing an interface for creating accounts in a web application. Note that this interface is to be used by the administator to create accounts and will not be used for users signing up.

I have designed the edit account screen and am quite happy with it:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Note that each tab is discrete and contain its own save button.

This works very well for editing a user account as administrators can easily zero in on the information they need or wishes to edit.

The problem is that when it comes to designing an interface for creating accounts. In this case, there is no sense in having individual buttons for each tab, so I have moved it outside like so:

mockup

download bmml source

The fields have the following characteristics:

  • Profile contains the user's name and any other fields the system administrator has defined. The fields here are visible to all logged in users.

  • Preferences contain settings like timezone and language. It also contains any other fields that the system administrator has defined and is not visible to anyone except for system administrators and the user himself.

  • Email addresses come in 2 forms (depending on how the administrator has configured the system):

    • Where multiple addresses can be linked to an account, an interface to add, remove and make an email address primary.
    • Where only one email address is allowed, a simple text field to change the user's email address.
  • Addresses can be disabled (will not show up in the tabs), contain a set of address fields defined by the administator (postal address, home address, etc) where some address fields can be marked as required or be in multiple address mode where multiple addresses can be added and removed.

  • Roles essentially allows the administrator to view the user's assigned roles and modify them.

  • Groups allow the admin to view the user's groups and modify them.

As per the above, when it comes to editing a user, there are many parts of the account that is editable and can become too complex if everything is shown as just 1 form.

As per the mockup (second image) of my "creating user" UI, there seems to be a few problems:

  • I feel uneasy about using "tabs" in a "create account" UI because it doesn't not really seem to impose a direction of flow/progression.
  • While accordions can impose a flow direction, some screens in the accordion can be large, resulting in a lot of scrolling.
  • Should we only show fields that are required, for example, in this case, combine all require fields in profile, preferences, email addresses, addresses into 1 form, and then have seperate forms for roles and groups?
  • However, if we only show required fields, it would be very annoying for the administrator to create a user account, and then go and edit it to fill in the rest of the fields (if he needs to fill them).

Are there any better ways to do this? Are there any screenshots/examples/information from applications that solve this problem?

share|improve this question
    
You could imply direction by adding numbers to your tabs... –  ph33nyx May 2 '13 at 14:25
add comment

2 Answers

I've come accross this a number of times when working on CMS interfaces - it can be very awkward. The common solution, which you did mention, is to collect all fields that are strictly necessary in order to create the object (in this case an account), relying on sensible defaults or null values for the rest (with those other tabs hidden) and then after submission taking the user directly to the 'edit' version with the rest of the tabs visible so that they can make any other changes if necessary.

share|improve this answer
add comment

You may not like this answer but I have dealt with this issue many times. I highly recommend a spreadsheet style interface or, since the development cost is so high, employ an excel/csv upload interface.

That's the answer. Here's my support for it: The Persona/User story for an administrator is vastly different from the typical user you might intuitively picture.

The Persona: Usually a highly proficient user in charge of implementing the project that the application is associated with. They often have an excel list of existing users that they want to enter. Either from an existing database export or created. They are almost always Excel power users. The interface of excel will appeal to them much more than a wizard.

The user story: They will have a long list (10+, 50+ 100+...?) of people to enter. One at a time will be tedious and they will resent the system, no matter how easy you make it. They need and if they know enough, will demand batch upload. Secondly, they will want to enter all information at once. And oftne, most of the information repeats for each entry; only name and personal info differ. Tabs and screens will add countless clicks to their task And on most of the secondary screens, the same info will be entered repeatedly. That should be enough to convince you.

I suggest a spreadsheet upload because Excel (or similar spreadsheet programs) have perfected the interface for this kind of data entry. Uploading a csv make the user's job easy and leads to less mistakes as well as the high cost of recreating a spreadsheet interface bug free on a web app. The browser is really not geared for this level of interaction.

The web app interface for this can be very sophisticated and meaningful.

  • Make a simple upload with instructions on the file format.
  • Parse the file on submit. and return the row count and other meaning ful meta data.
  • also display a table of the data upload for the user to review and allow them to delete or perhaps edit the parsed results.
  • They can then re upload or commit the results.

Trust me, your intended user base will appreciate this kind of interaction.

PS There are some jQuery plugins out there for emulating spreadsheets. Keep in mind they emulate it. They may be worth looking into.

I hope this puts you in a good direction.

share|improve this answer
1  
I recently attended a talk about "Big Data". The speakers were discussing the concept of NIH (Not Invented Here). The concept in software development is that people come into engineering a product and ignore existing technology and invent their own solutions that often fail. They fail because they end up missing the hidden issues that have already been solved elsewhere. It encouraged my POV I express in this post that leveraging existing technology is a smart choice. I love inventing new ideas but i'll take pragmatism and happy users any day. –  Itumac Oct 23 '12 at 2:29
    
why not a hybrid? Start with an import of everything the admin does know, including the minimum data required to create that person object, and then a web interface it add to and modify what was imported. Ideally you would test your users in some way, even within admin there is a wide range of skill sets and mental models. –  ph33nyx May 2 '13 at 14:25
    
This is what I call thinking out of the box! –  Dvir Adler Aug 13 '13 at 8:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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