Challenge Summary
Welcome to the “HealthPlan Services Admin Portal UI Design Challenge”! The scope of this challenge is to design the UI of an internal web application for HealthPlan Services (HPS), who is a provider of health insurance plans. It will manage the documentation for onboarding customers and defining their insurance plan benefits.
Today the documentation is managed with a combination of many Word and Excel files. With this new Admin Portal application, users will have current data in one place. They will be able to easily customize documents, add data, update information and track changes.
Please read the challenge specifications carefully and let us know if you have any questions in the forums.
Template Admin User
1.Templates Landing Screen
2.Create New Template
Contributor User
1.Documentation Landing Screen
2.Edit Documentation - Admin Summary
4.Publish - Admin Summary or Benefits Summary
Template Admin User
1.Templates Landing Screen
2.Create New Template
Contributor User
1.Documentation Landing Screen
2.Edit Documentation - Admin Summary
3.Edit Documentation - Benefits Summary
4.Publish - Admin Summary or Benefits Summary
5-6.View Document - Admin Summary & Benefits Summary
7. View History
CHALLENGE OBJECTIVES
PROJECT OVERVIEW
EXPLORATION SCORE
GLOSSARY
Benefits Plan, Insurance Plan: An agreement to provide some amount of coverage for healthcare expenses, typically offered as a benefit with employment.
Admin Summary: The documentation required to identify and onboard a customer.
Benefits Summary: The documentation needed to define what is included/excluded in the customer’s insurance plan.
BACKGROUND
HealthPlan Services (HPS) provides health insurance plans for large companies whose employees receive the benefits. We are designing an internal application to simplify the management of many administrative documents needed to set-up and organize the details of each benefits plan. The customers of HPS are large employers (companies like Target or HP) and require a huge amount of data to be collected and recorded related to their health insurance benefits. These benefits plans are changed often. Moving the management of this data and documentation to an online system will simplify the process for those employees responsible.
For this new system, we will focus on bringing two specific types of documentation online:
Admin Summary. This documentation captures all the data needed to onboard a new customer. It keeps track of a customer’s business details such as banking details, contact information, address, etc. Each customer will have an Admin Summary document.
Currently, the people who onboard customers use a Word document which involves a lot of manual data entry and maintenance on a regular basis. It also creates issues around version control which could lead to incorrect values being entered into Admin Summary.
Benefits Summary. This documentation pertains to defining the benefits that are included/excluded in a customer’s plan. It contains all the definitions of benefits for a particular insurance plan. One customer may have several different insurance plans.
Currently, the Benefits Summary data is managed using Excel spreadsheets which are maintained manually. This increases the workload for all the team members who are engaged, and increases the amount of maintenance needed. It is difficult for users to keep control of the versions and changes made in these docs.
What the new application should do:
TARGET USERS
A wide variety of users from both HPS and their customers will use the application. For example: Project Managers who manage business with customers; Agents who onboard new customers; Business Analysts who look at value of benefits; Benefits Managers who are human resource representatives of employers.
There are several user roles that have specific functionality tied to them. We will be addressing two in this challenge.
Lifecycle of documentation (For example: Admin Summary or Benefits Summary)
This illustration shows a simple diagram of the documentation lifecycle, which is detailed below.
SCREEN REQUIREMENTS
Global Elements
USER: Template Admin
1. Templates Landing Screen
Users arrive at this Admin Portal screen from another area of the HPS platform. A Template Admin user may see a variety of templates they have built for various customers. Our example includes 2 types of documentation (Admin Summary and Benefits Summary). There could be more document types in the future.
2. Create New Template
The first template of each type would have nothing entered as content. The user will create this template from scratch. The user would be able to create sections and then define each item with details. The user will add data items one by one, or the user will add an entire section (multiple fields and variables) all at once. Once a template has been created, it may be copied to use as a starting point to create a new template.
Be creative! Explore various ways the user can build a template with many pieces.
After a template is complete, it is saved for a specific customer. The Contributor is then able to access this saved document and enter all of the required information and selections.
This challenge scope will focus on creating 2 types of templates: Admin Summary and Benefits Summary. There will be multiple instances of each type that are unique for different customers. The application will expand to create other types of documentation in the future.
The provided spreadsheet outlines sample fields and sections a template might have. Notice the fields and variables shown for the Admin Summary (rows 16-64), and then those for the Benefits Summary (rows 66-152).
USER: Contributor
1. Documentation Landing Screen
After a template has been created for a customer and saved as a document, it is available for data entry by a Contributor.
2. Edit Documentation - Admin Summary
Example of an Admin Summary document
The user reaches this screen by clicking one of the Admin Summary documents from the landing page. Here they will make changes or complete data entry.
Be creative! Explore various methods to move through the different sections and items. Let users choose which sections they want to work on.
3. Edit Documentation - Benefits Summary
Example of a Benefits Summary document
Same functionality as for 2. Edit Documentation - Admin Summary. Explore the solution using the sample content for Benefits Summary.
4. Publish - Admin Summary or Benefits Summary
The Publish function would begin an automatic process to check the documentation to determine if all required items have been completed. If all requirements were met, the user will receive a success message that their document was published. If there were errors or missing items, the user will receive an error message and a list of the items still needing data. This is the same for any type of document.
Be creative! These documents can be very lengthy. How might the user easily see what areas need attention? How would they fix them efficiently?
5-6. View Document - Admin Summary & Benefits Summary (2 pages)
Once a document has been published, a user is able to view it online within the application. The file can then be exported as a PDF or other format. This view is often shared with customers and stakeholders. Please show an example of both the Admin Summary and the Benefits Summary.
Think about how this View display of a published document should be different from the Edit display of the same content.
7. View History
The user should have access to the past versions of published documents and know which elements have changed.
When the user selects an existing version of a document, they should be able to see which elements have changed from previous versions. Consider a solution showing side-by-side comparison with highlighted elements, or a simple list of differences.
Be creative in solving the functionality for this feature. There are many version control softwares out there to do research on good options.
Note: The Admin Summary and Benefits Summary histories may be shown combined or as separate views, depending on your solution.
BRANDING GUIDELINES
SIZE
Desktop: Width 1440px x Height as much as needed
STOCK PHOTOS AND ICONS
MARVEL PROTOTYPE
FINAL DELIVERABLES
Today the documentation is managed with a combination of many Word and Excel files. With this new Admin Portal application, users will have current data in one place. They will be able to easily customize documents, add data, update information and track changes.
Please read the challenge specifications carefully and let us know if you have any questions in the forums.
Round 1
Submit your initial designs for checkpoint review. Feel free to add any screens which are necessary to explain your concept.Template Admin User
1.Templates Landing Screen
2.Create New Template
Contributor User
1.Documentation Landing Screen
2.Edit Documentation - Admin Summary
4.Publish - Admin Summary or Benefits Summary
Round 2
Submit your final designs plus checkpoint feedback implemented. Feel free to add any screens which are necessary to explain your concept.Template Admin User
1.Templates Landing Screen
2.Create New Template
Contributor User
1.Documentation Landing Screen
2.Edit Documentation - Admin Summary
3.Edit Documentation - Benefits Summary
4.Publish - Admin Summary or Benefits Summary
5-6.View Document - Admin Summary & Benefits Summary
7. View History
CHALLENGE OBJECTIVES
- UI design for a desktop web application
- Create approximately 10-15 unique screens
- Provide a seamless experience for users to create, update, track and publish documents
PROJECT OVERVIEW
- The purpose of this challenge is to develop the HealthPlan Services (referred to as HPS) Admin Portal that will include capabilities to fully manage data for onboarding customers (Admin Summary documentation) and defining their insurance plan benefits (Benefits Summary documentation).
- Users will have the ability to create unique templates for various customers. They will also be able to populate the data into saved documents and edit as often as needed to create final documents. The experience should be easy and intuitive.
EXPLORATION SCORE
- Creativity: Conservative; use conventions that are intuitive and proven to work.
- Exploration: Flexible; use the provided screen requirements as a base, and propose improvements that positively impact the user goals.
- Aesthetics: Hi-fidelity design; provide a top-notch finished-looking visual design.
- Branding: Flexible; Must use provided header/footer design. Use provided fonts and color palette, but the rest is up to you.
GLOSSARY
Benefits Plan, Insurance Plan: An agreement to provide some amount of coverage for healthcare expenses, typically offered as a benefit with employment.
Admin Summary: The documentation required to identify and onboard a customer.
Benefits Summary: The documentation needed to define what is included/excluded in the customer’s insurance plan.
BACKGROUND
HealthPlan Services (HPS) provides health insurance plans for large companies whose employees receive the benefits. We are designing an internal application to simplify the management of many administrative documents needed to set-up and organize the details of each benefits plan. The customers of HPS are large employers (companies like Target or HP) and require a huge amount of data to be collected and recorded related to their health insurance benefits. These benefits plans are changed often. Moving the management of this data and documentation to an online system will simplify the process for those employees responsible.
For this new system, we will focus on bringing two specific types of documentation online:
Admin Summary. This documentation captures all the data needed to onboard a new customer. It keeps track of a customer’s business details such as banking details, contact information, address, etc. Each customer will have an Admin Summary document.
Currently, the people who onboard customers use a Word document which involves a lot of manual data entry and maintenance on a regular basis. It also creates issues around version control which could lead to incorrect values being entered into Admin Summary.
Benefits Summary. This documentation pertains to defining the benefits that are included/excluded in a customer’s plan. It contains all the definitions of benefits for a particular insurance plan. One customer may have several different insurance plans.
Currently, the Benefits Summary data is managed using Excel spreadsheets which are maintained manually. This increases the workload for all the team members who are engaged, and increases the amount of maintenance needed. It is difficult for users to keep control of the versions and changes made in these docs.
What the new application should do:
- Bring all the possible content sections within Admin Summary and Benefits Summary into an online process. Eliminate need for Word and Excel docs.
- Allow users to create custom templates with inputs based on each customer's intent. Ability to choose to include only sections that apply to that Customer. Sections and fields within the documentation should be customizable.
- Data could include:
- Admin Summary - Who the customer is; Elements they are electing; Clerical details such as banking arrangements, etc.
- Benefits Summary - Definitions of the benefits that are included/excluded in the insurance plan.
- Allow users to easily make changes to customer information at various times. For example: annual plan renewals, or throughout the year if needed.
- Provide options to complete sections much more easily than it is today. For example: auto-fill from previous entries, include default data where possible.
- Automatically save and track changes that are made to data.
- Publish completed documents and allow multiple versions for customers.
- Automate the processes to gather, update and use this data elsewhere. Store data that could be used with other systems in the future.
TARGET USERS
A wide variety of users from both HPS and their customers will use the application. For example: Project Managers who manage business with customers; Agents who onboard new customers; Business Analysts who look at value of benefits; Benefits Managers who are human resource representatives of employers.
There are several user roles that have specific functionality tied to them. We will be addressing two in this challenge.
- Template Admin:
- An HPS employee who is responsible for defining all the data to be included in the documentation.
- They have the ability to Create a New template for any type of documentation, and to edit existing templates.
- They typically create a unique version for a specific customer.
- At their Landing screen, this user will see a list of templates they have created. Some will be complete and some in-progress. Their list may include multiple instances of each type of document that they have created for various customers.
- Contributor:
- An HPS employee who supports multiple customers and their benefits plans. Or, an employee of a customer company responsible for managing the benefits plans.
- Once a document has been created for them, they have the ability to complete (enter) document details and make the selections for benefits plans.
- They typically complete, edit, and publish a document.
- At the Admin Portal landing page their list could include multiple of each type of document, depending on their position.
Lifecycle of documentation (For example: Admin Summary or Benefits Summary)
This illustration shows a simple diagram of the documentation lifecycle, which is detailed below.
- Template Admin: A new document Template is created from scratch. Each template includes a unique combination of data elements as designed by the Template Admin.
- Template Admin: An instance of a template is saved for a specific customer. At this point, it becomes documentation which must be completed before being published.
- Contributor: Data is entered and/or selections are made to complete the documentation needed.
- Contributor: Completed documentation is published so it may be distributed to customers and/or stakeholders for review.
- Contributor: A published document version is viewable online within the system or via external file (pdf). View only.
- Contributor: Completed documentation may be edited by a contributor and saved or published. This could be done multiple times per year and may generate multiple versions of the published documents.
- Contributor: Past published versions of documents are available for access via history. History should indicate which elements have been changed with each version of the documentation.
- Future functionality: Current and past data as entered could be accessed by other systems
SCREEN REQUIREMENTS
Global Elements
- The header and global navigation should be used as shown in this file. This must be included as-is on all screens. The Admin Portal UI will exist only in the content area of each screen.
- Note: User is already logged into the HPS platform. The platform login and home are NOT part of the prototype. Only design the content areas of the screens.
USER: Template Admin
1. Templates Landing Screen
Users arrive at this Admin Portal screen from another area of the HPS platform. A Template Admin user may see a variety of templates they have built for various customers. Our example includes 2 types of documentation (Admin Summary and Benefits Summary). There could be more document types in the future.
- Display a selection of the existing templates accessible by this user. Organized for the user. For example: By document type, By customer, Completed vs. Incomplete.
- User must have the ability to access each template for editing or adding content.
- User must have the ability to make a copy an existing template to use as a starting point for a New Template.
- Give the user a clear path to Create New Template as a button or link to start a brand new template.
2. Create New Template
The first template of each type would have nothing entered as content. The user will create this template from scratch. The user would be able to create sections and then define each item with details. The user will add data items one by one, or the user will add an entire section (multiple fields and variables) all at once. Once a template has been created, it may be copied to use as a starting point to create a new template.
Be creative! Explore various ways the user can build a template with many pieces.
After a template is complete, it is saved for a specific customer. The Contributor is then able to access this saved document and enter all of the required information and selections.
This challenge scope will focus on creating 2 types of templates: Admin Summary and Benefits Summary. There will be multiple instances of each type that are unique for different customers. The application will expand to create other types of documentation in the future.
The provided spreadsheet outlines sample fields and sections a template might have. Notice the fields and variables shown for the Admin Summary (rows 16-64), and then those for the Benefits Summary (rows 66-152).
- New Template Info:
- Document Type (For example: Admin Summary, Benefits Summary)
- Name New Template
- Line of Business
- Group (For example: Large, Small)
- Font Styles
- Document Sections / Subsections
- May be: re-ordered, added/deleted, modified.
- Will vary depending on the Template Admin’s design.
- Examples from spreadsheet: General Information, Consumer Directed Health Care, Plan Sponsor Contact Information (note: the spreadsheet is showing sample fields for both types of documentation)
- Data Items
- May be: re-ordered, added/deleted, modified.
- Data Items could be simple (single description w/ form field) or very complex (table with multiple descriptions and field options)
- Each item includes:
- Description (label to display)
- Form element type, possible values, default value
- Options: required, additional text, hover notes, conditional behavior/content, etc.
USER: Contributor
1. Documentation Landing Screen
After a template has been created for a customer and saved as a document, it is available for data entry by a Contributor.
- Display a list of documents available to the user. This could be organized by document type (Admin Summary or Benefits Summary), by Customer (if they manage more than one customer), by status (Completed vs. Incomplete).
- User must have the ability to access a document to enter and edit information as needed.
- The user must be able to see which documents are incomplete and need attention before they are publishable.
- Each document could be edited and published several times. This will make it necessary to display the multiple versions that exist, and indicate which is the current version.
2. Edit Documentation - Admin Summary
Example of an Admin Summary document
The user reaches this screen by clicking one of the Admin Summary documents from the landing page. Here they will make changes or complete data entry.
Be creative! Explore various methods to move through the different sections and items. Let users choose which sections they want to work on.
- Allow the user to enter data and make selections from the choices provided in the template. They will complete the document with the required data and selections that have been set-up in the template.
- Give the user a clear path to Publish this version of the document
- Give the user the option to Save a document that is in-progress and not yet completed.
3. Edit Documentation - Benefits Summary
Example of a Benefits Summary document
Same functionality as for 2. Edit Documentation - Admin Summary. Explore the solution using the sample content for Benefits Summary.
4. Publish - Admin Summary or Benefits Summary
The Publish function would begin an automatic process to check the documentation to determine if all required items have been completed. If all requirements were met, the user will receive a success message that their document was published. If there were errors or missing items, the user will receive an error message and a list of the items still needing data. This is the same for any type of document.
Be creative! These documents can be very lengthy. How might the user easily see what areas need attention? How would they fix them efficiently?
5-6. View Document - Admin Summary & Benefits Summary (2 pages)
Once a document has been published, a user is able to view it online within the application. The file can then be exported as a PDF or other format. This view is often shared with customers and stakeholders. Please show an example of both the Admin Summary and the Benefits Summary.
Think about how this View display of a published document should be different from the Edit display of the same content.
7. View History
The user should have access to the past versions of published documents and know which elements have changed.
When the user selects an existing version of a document, they should be able to see which elements have changed from previous versions. Consider a solution showing side-by-side comparison with highlighted elements, or a simple list of differences.
Be creative in solving the functionality for this feature. There are many version control softwares out there to do research on good options.
Note: The Admin Summary and Benefits Summary histories may be shown combined or as separate views, depending on your solution.
BRANDING GUIDELINES
- Follow the HPS branding for colors only
- Use the header and footer from the existing platform
- Font: use Open Sans family
SIZE
Desktop: Width 1440px x Height as much as needed
STOCK PHOTOS AND ICONS
- Photos are allowed in this challenge
- Icons: you can only use icons as allowed by Topcoder icons policy
- Fonts: use customer fonts - Gotham Family
MARVEL PROTOTYPE
- Upload your screens to Marvel App.
- Send your marvel app request to keyla. blue1@gmail.com or ask in the forums
- Include your Marvel app URL as a text file in your final submission. Label it “MarvelApp URL”.
FINAL DELIVERABLES
- An archive called Source.zip file to include:
- All original source files created in Sketch, XD, Figma
- An archive called Submission.zip file to include:
- All your design files in PNG or JPG format
- MarvelApp link for review and to provide feedback
- Your declaration files to include any notes about fonts usage, photo and icon declaration and link to your Marvel project
- Create a JPG preview file of 1024 x 1024 px
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.