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'm working on an application page for an insurance company regarding purchasing policies and showing all the detailed information that comes with the policy.

The problem I'm facing is knowing how to appropriately show the detailed information for each policy since there can be anywhere from 1-5 policies that holds 10-50 detailed items in a list. (These also have prices associated for each item).

You could say it's similar to buying multiple computers with a list of every computer part and price included.

enter image description here

This is the current design I have. I contemplated hiding the detailed list and adding a "View Details" link underneath each summary policy, but I can't imagine how legible it would be to show a table inside of another table. Any help would be appreciated?

share|improve this question
2  
The "master-details" tag is dedicated to questions of this nature; I suggest you look at some that have previously been answered: ux.stackexchange.com/questions/tagged/master-details –  Sam Blake Feb 20 '13 at 15:11

4 Answers 4

I would look at following some of the patterns that you would see in iOS or Android applications for this. It wouldn't be very different from what you have now, but it would be both easy to use and easy to implement.

Make it clear visually that the first view is a list of selectable items. Then when you select an item in the list view, you could show the detailed view as a modal. If you need to interact with the items on this level, I would consider having a separate page for them, which would make that interaction easier.

share|improve this answer
1  
I would not suggest blindfoldly to follow mobile-patterns onto a desktop pattern with as much detail as the author wants. –  Bluewater Feb 20 '13 at 12:38

I can't comment it seems, so had to stick this into an answer node. Having recently dealt with re-insuring my car, from what I could make of it there's more to it than just expanding or fly-out lists of detail that are arrived at by a simple search to get to policies. It seemed to me the database structure is much flatter and information more mashable than simple hierarchies of detail. You'll need to find out more how the insurance agents typically interact with this information, before deciding on a design. I don't see any opensource insurance apps to have a look at.

share|improve this answer

The classic solution to this problem is to use master-slave tables. In the master table the list is displayed and in the slave table, the details for the currently selected item. Of course, the "table" term is used conditionally: it can be tree or other data representation form, depending on the nature of the displayed information.

Depending on the size of the details information, some hint-on-hover window can be provided for quick overview of the information. Although it will be useful only if the detailed information is small enough.

share|improve this answer

As you mention something around 1-5 policies with 10-50 items each, what about using some sort of accordion for your policies that you can use to show/hide the details in a sub-table for each policy?

Something like this:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Edit: removed the scroll bars following Charles' advice

share|improve this answer
    
+1 This is the answer I would have given. This is a text book use case for a master/detail or drill-down design pattern. However I would not have scroll bars within the detail view, and I would ensure that the user has the ability to expand all of the accordions at the same time if they wish. –  Charles Wesley Feb 20 '13 at 16:31
    
@Charles Thanks for your comment! Regarding the scroll bars, would you mind to elaborate a little on why you would avoid them? Thanks! –  Yannick Blondeau Feb 21 '13 at 8:43
1  
A summary/detail view has an implicit contract of "expand the summary to view the details". If one wanted to see all of the line items, they would try to expand the summary views. Removing the nested scrolling would allow the browser's native scrolling based on their viewport only when needed. Artificially introducing nested scroll bars is a huge UX hit without a compelling positive return benefit that exceeds the cost. Nested scrolling requires users to store detail data in their short term memory when it is out of view which increases cognitive load. –  Charles Wesley Feb 21 '13 at 16:52
1  
See related thread for more on this topic: ux.stackexchange.com/questions/396/… –  Charles Wesley Feb 21 '13 at 16:54
    
@Charles Thanks for taking the time to help me learning! –  Yannick Blondeau Feb 21 '13 at 19:53

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.