Challenge Summary
Welcome to "Client Self-Serve Portal - Wireframe Challenge". In this challenge, we are looking for you to help plan a great user experience for a government organization's Client Self Service Portal. The purpose of this challenge is to create an intuitive (wireframe) interface and interactions that expand a user's self-service capabilities for transactional services. Please check out more details below!
At the end of this challenge, we are looking to see easy to use "wireframe concepts" that will help us design and build the user interface and continue to improve the user experience in the next phase of this project! The best portal designs will be the ones that consider the end-to-end challenge statement and the related user experience!
1. Login
2. Client Dashboard
3. Account Management Process
4. Application Process
1. Login
2. Client Dashboard
3. Account Management Process
4. Application Process
5. Application Renewal Process
6. Document Management Process
7. Submission and Communication Process
8. Viewing Services Summary Information
Background Overview
We are developing a client Service Portal to expand client access to self-service capabilities for transactional services. Specifically, the portal will provide parents the ability to apply online for public programs and benefits for their children, view approved services and communications, notify participating business areas of changes that affect approved services, and communicate electronically with program staff within the secure electronic environment. Our goal is for the portal to become a new trusted resource for parents.
Challenge Goals
Create Client Service Portal that improves access to online self-service capabilities and provides clients with more flexibility. This will have several benefits including:
-- Improved accuracy for application completion
-- Integration of forms with primary database application
-- Broadcast messages from organization to portal users
-- Reduced organizational phone queue volumes, paper, printing, and mailing costs
Scope:
The new Client Service Portal digital strategy is proposed to improve access to program services for two program areas initially.
- Program A: User can view enrollment status, receive expiry/renewal reminders, make changes to approved services, submit documentation electronically, and send and receive messages with program staff.
- Program B: User can apply for services, view eligibility status, receive expiry/renewal reminders, notify of changes that may affect eligibility, submit documentation electronically, and send and receive messages with program staff.
Please note - the general information flow, user interaction, and processes are very similar for each of these programs defined above and in the attached documentation. However, there may be some subtleties that will be incorporated in your wireframes. For the purposes of this challenge, we will focus on the general portal requirements and a few requirements specific to Program B.
Flow Requirements
Below are a list of suggested screens for the application. Please note that these are merely suggested - if you can think of ways to combine functionality and improve the user experience – please do. Several of these processes could be extended over several screens or combined into one. We would like you to use your experience to design the best user experience and information flow for this client self-service portal. Please note that you do not always need to build the downstream screens or functionality, we just want to get a good idea for how the user will navigate the portal and how the information will flow.
The key processes and requirements for the portal are summarized below. However, there is additional information available in the attachments. The attached document includes process diagrams, user stories, functional requirements, business rules, and other supporting details for this project. Please note that the out-of-scope user stories and requirements have been "grayed" out to indicate they they are not in scope for this wireframe challenge. They have been left for your reference as this is helpful context for understanding information flow.
1. Login Screen
- User needs to be logged in first before able to use the application
- Provide login form fields (username/password/remember me/login button)
- Provide error condition if user enter wrong credential
- Provide link for "Forgot password" and "Register" features.
-- Note: for this challenge you can assume a user is already registered for the portal - you do not need to build out the downstream screens for the Registration process.
2. Client Dashboard
We would like for you to build a dashboard for the portal user. This dashboard will serve as the homepage for the client as he / she navigates the portal. The following should be considered as you design the wireframe for the dashboard:
- User should be able to navigate to other portal functionality (e.g. Manage Account, Initiate Application Process, View Services Summary) from dashboard
- Based on requirements and understanding of the client challenge, please include other information or content which may be helpful for a client:
-- View / access notifications here
-- Status bar to show status of services, applications, messages, etc.
-- Help / Support
- Show us your creativity for the dashboard area, what is important information that needs to be shown in this page? How can this page improve the overall the user experience?
3. Account Management Process
There are several sub-processes within account management. Please be creative with how you design the account management process based on the following user stories and requirements.
View / edit communication method: A portal user wants to set-up communication profile, so that he / she can receive notifications about activity on account via chosen communication method and opt out or change said method when necessary, so that he / she can receive notifications pertaining to portal dashboard. The portal must provide:
- The ability for a portal user to choose their communication method, email, SMS text or both, for notifications pertaining to their portal dashboard.
- By default, Portal Communication Method is active and set to email.
View / edit non-primary access: A portal user wants to be able to grant (possibly more limited) access for another individual(s) to portal dashboard, so that they can manage the program services together (e.g. two parents on one account). For clarity, we shall refer to this individual as the non-primary client. The portal must provide:
- The ability for the portal user to grant/revoke access for non-primary clients. Depending on the program, access for each non-primary client may differ.
- The ability to time-bound (to/from date) the portal access of each non-primary client.
- The ability for a Program B portal user to grant/revoke access for the non-primary clients to messaging and documents management in their dashboard.
View / edit account information: A portal user wants to be able to change contact information via the portal, so that the program areas has up-to-date information on file. The portal must provide:
- The ability for a portal user to change designated contact information (address, for instance) within the portal, and for the program area to be notified and/or require approval prior to changes to specific elements of contact.
Deactivate portal account: A portal user wants to be able to unregister for services, so that he / she doesn't receive services through the portal and/or the program anymore.
4. Application Submission Process
Through the application process, a user should be able to apply for new child program services through the portal so that he/she can receive program services and manage services online. Please develop your wireframes and user interaction flow to create the best user experience for the application process, it should be intuitive and clear for new users to navigate. The following are the key portal user stories which must be covered by the application process:
- Save and resume an unsubmitted application, so that users do not have to re-start the application process
- Edit a submitted application, so that user can update information prior to the program area working on it
- Delete a submitted application, because user no longer wish to apply for services, so that user doesn’t submit unneeded applications.
- Cancel an in progress application, so that user can withdraw application for services.
- Leverage previous submissions, so that user does not have to re-enter/supply redundant information.
- View historical submissions information, so that user has a complete record of all submissions made for services.
- View all communication between user and the program area that has been conducted through the portal
Key Requirements for the Application Process (see attached documentation for additional details):
- The ability for the application process to provide a guided, intuitive format, along with explanatory text and help/support functions.
- The ability to indicate mandatory fields to the portal user, as well as non-editable information.
- The ability to help orientate the portal user to where they are in the application process (i.e. progress bar).
- The ability to present the portal user with a listing of required documentation that needs to be submitted with an application, based on the answers captured during the application process.
- The ability for a portal user to electronically sign their application prior to submission.
- The ability for an application submitted through the portal, in "Submitted" status, to be recalled by the portal user and edited, if business rules allow.
- The ability for an application submitted through the portal, in "Submitted" status, to be recalled by the portal user and deleted, if business rules allow.
- The ability for an application submitted through the portal, in "In Progress" status, to be cancelled by the portal user through a portal request.
- Once a submitted application is being worked on in the primary database system, the application is locked on the portal and no further changes can be made by the portal user.
Additionally, the application for services (e.g. care) should include the following information:
-- Applicant Contact Information is general contact information (name, address, phone, etc.)
-- Applicant Status (Resident, Proof of Status) – this is a public government program so this is applicant’s proof of residency.
-- Applicant Need for Care (Days and Times for Care) is the demonstrated need for child care (days of the week + times that a child would need care)
-- Applicant Marital Status Information (Spousal Information) is married, single, divorced, etc.
-- Spouse's Need for Care is the same information as provided by the applicant - days and times that the spouse's schedule would require child care
-- Income Information
-- Care Recipient Information is the information for the child receiving care (name, birthdate, school information, allergies, special needs, etc.)
-- Dependent Information (Dependents supported by the household)
-- Declaration is the electronic signature block (includes confirmation of information and consent to disclose)
The applicant should also attach* the following documentation to his / her application for services:
- Proof of Status
- Proof of Employment (Pay Slips or Proof of Self-Employment)
- Proof of Registration for Educational Institution (if applicable)
- Proof of Medical Condition (if applicable)
- Proof of Government Disability (if applicable)
- Spousal Identification (Government Issued)
- Care Recipient(s) Identification (Government Issued)
*Note that there are a specific set of requirements for document uploads and document management. Please refer to “9. Document Management Process” below.
5. Application Renewal Process
For those users who have already submitted an application for services and have received services - the application renewal process should also be able to be managed and performed through the portal. Please consider the best way to include the following use cases in your wireframes:
- A portal user wants to receive reminders prior to renewal being due, so that he / she can renew program application (including required documentation) or status in a timely manner.
- A portal user wants to be able to renew expired application on the portal, so that program services continue.
6. View Services Summary Information
View Services Summary: A portal user wants to view services summary, so that he/she has current services information. The services summary should display the following information:
- Yearly Services Amount (amount of funding/services awarded)
- Current and Previous Year Services disbursement Information
- Available Services Balance
Inquire on Services Summary: A portal user wants to be able to make an inquiry about services summary through the portal, so that he / she can resolve a question.
7. Submission and Communication Process
A portal user should be able to send and receive general and specific messages and requests through the portal. This messaging process may be initiated on its own, based on a specific request from a user, or this may be triggered by another portal activity (such as updating certain account information. For this wireframe challenge the messaging scope is restricted to the general messaging processes for the portal. This includes:
- A portal user wants to send a general message to the business area, so that he / she can initiate a conversation.
- A portal user wants to send a request to the business area, so that he / she can initiate an action on his / her case.
Key Requirements for Submission and Communication Process (please refer to attached documentation for additional details):
- The ability for a portal user to communicate with a program area regarding a general question around their program services
- The ability for a portal user to request a cancellation of their request with a status of "In Progress"
8. Document Management Process
It is important to note that the document management process is a supportive process for other processes, such as the application and renewal processes. For example - the user should be able to upload documents and submit them as part of an application for services. As you analyze the problem and think through the user interactions with the client portal, please use your expertise to incorporate document mgmt where it is appropriate in the designs.
Key Requirements for Document Management (see attached documentation for additional details):
- The ability to upload documents and photos to the portal.
- The ability to attach documents and photos to an application or message in the portal
- The ability to save locally and to print (in printer friendly format) documents, photos, applications and forms accessible through the portal
- The ability for the portal user to manage/filter the documents and photos they see in their portal view
- By default, Portal Documents will show current and last year activity (2 years backward facing) on a case. (older historical submissions should be viewable by the user through adjusting view settings.)
Notes on Attached Documentation
- The attached documentation includes process diagrams, user stories, functional requirements, business rules, and other supporting details for this project.
- Please note that the out-of-scope user stories and requirements have been “grayed” out to indicate they they are not in scope for this wireframe challenge. However, they have been left for your reference as this is helpful context for understanding information flow / details.
Wireframe Expectations:
- Produce HTML click through wireframes that can be used to demonstrate all mentioned functionalities as required in each round.
- The wireframe must be very easy to use and intuitive. Keep that in mind when designing your solution.
- You MUST cover all screens mentioned in required sections below, if any requirement is missing in final submission the client will not look at it, so make a checklist for the required screens to make sure you designed all of them.
- Please show us your proposal as a movie or series of wireframes that communicate the user’s intended interaction with your proposed solution.
- You MUST use wireframes note pane in every single page you design to explain what items are addressed in that page from the documentation, what things you added/changed/removed, use it to make your idea clearer and help the client to give you constructive feedback.
Target Devices
- Desktop : Width 1024px (height can expand as needed)
Target User
- This challenge will focus on a portal client user (referred to in attached documentation as "PU"). Portal users are primarily parents with children under 18
-- Although the Requirements document references additional Business User ("BU") stories, this challeng will focus on the client use cases.
-- The requirements documentation has left the business user information and other out-of scope requirements in for your reference as this is helpful context for understanding information flow / details.
Learn Axure:
New to Axure? Here are some quick tutorials to help you get started.
http://www.axure.com/learn
Judging Criteria
- Overall User Experience
- Completeness and accuracy of the wireframe as defined in the challenge spec
- How well your wireframes provide a consistent user flow.
- How well your wireframe captures all the functionality.
- Any suggestions, interactions and user flows you recommend (provide any notes or comments for the client).
Submission and Source Files
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
All requested contest requirements as clickable HTML files generated by Axure. All the content must be listed and the pages are linked together to show page flow.
Source Files
- Wireframes should be built in Axure. The resulting source files used to generate the clickable HTML files.
- All the content must be listed and the pages are linked together to show page flow.
- All fully editable original source files of the submitted wireframe as required by the contest under "Source Files" in the sidebar should be included in your Source zip file.
Final Fixes
As part of the final fixes phase you may be asked to modify content or user click paths.
At the end of this challenge, we are looking to see easy to use "wireframe concepts" that will help us design and build the user interface and continue to improve the user experience in the next phase of this project! The best portal designs will be the ones that consider the end-to-end challenge statement and the related user experience!
Round 1
Your initial wireframes for client review should include the following functionality.1. Login
2. Client Dashboard
3. Account Management Process
4. Application Process
Round 2
All requirements as stated in challenge details with client feedback applied. Final submissions should include the following functionality:1. Login
2. Client Dashboard
3. Account Management Process
4. Application Process
5. Application Renewal Process
6. Document Management Process
7. Submission and Communication Process
8. Viewing Services Summary Information
Background Overview
We are developing a client Service Portal to expand client access to self-service capabilities for transactional services. Specifically, the portal will provide parents the ability to apply online for public programs and benefits for their children, view approved services and communications, notify participating business areas of changes that affect approved services, and communicate electronically with program staff within the secure electronic environment. Our goal is for the portal to become a new trusted resource for parents.
Challenge Goals
Create Client Service Portal that improves access to online self-service capabilities and provides clients with more flexibility. This will have several benefits including:
-- Improved accuracy for application completion
-- Integration of forms with primary database application
-- Broadcast messages from organization to portal users
-- Reduced organizational phone queue volumes, paper, printing, and mailing costs
Scope:
The new Client Service Portal digital strategy is proposed to improve access to program services for two program areas initially.
- Program A: User can view enrollment status, receive expiry/renewal reminders, make changes to approved services, submit documentation electronically, and send and receive messages with program staff.
- Program B: User can apply for services, view eligibility status, receive expiry/renewal reminders, notify of changes that may affect eligibility, submit documentation electronically, and send and receive messages with program staff.
Please note - the general information flow, user interaction, and processes are very similar for each of these programs defined above and in the attached documentation. However, there may be some subtleties that will be incorporated in your wireframes. For the purposes of this challenge, we will focus on the general portal requirements and a few requirements specific to Program B.
Flow Requirements
Below are a list of suggested screens for the application. Please note that these are merely suggested - if you can think of ways to combine functionality and improve the user experience – please do. Several of these processes could be extended over several screens or combined into one. We would like you to use your experience to design the best user experience and information flow for this client self-service portal. Please note that you do not always need to build the downstream screens or functionality, we just want to get a good idea for how the user will navigate the portal and how the information will flow.
The key processes and requirements for the portal are summarized below. However, there is additional information available in the attachments. The attached document includes process diagrams, user stories, functional requirements, business rules, and other supporting details for this project. Please note that the out-of-scope user stories and requirements have been "grayed" out to indicate they they are not in scope for this wireframe challenge. They have been left for your reference as this is helpful context for understanding information flow.
1. Login Screen
- User needs to be logged in first before able to use the application
- Provide login form fields (username/password/remember me/login button)
- Provide error condition if user enter wrong credential
- Provide link for "Forgot password" and "Register" features.
-- Note: for this challenge you can assume a user is already registered for the portal - you do not need to build out the downstream screens for the Registration process.
2. Client Dashboard
We would like for you to build a dashboard for the portal user. This dashboard will serve as the homepage for the client as he / she navigates the portal. The following should be considered as you design the wireframe for the dashboard:
- User should be able to navigate to other portal functionality (e.g. Manage Account, Initiate Application Process, View Services Summary) from dashboard
- Based on requirements and understanding of the client challenge, please include other information or content which may be helpful for a client:
-- View / access notifications here
-- Status bar to show status of services, applications, messages, etc.
-- Help / Support
- Show us your creativity for the dashboard area, what is important information that needs to be shown in this page? How can this page improve the overall the user experience?
3. Account Management Process
There are several sub-processes within account management. Please be creative with how you design the account management process based on the following user stories and requirements.
View / edit communication method: A portal user wants to set-up communication profile, so that he / she can receive notifications about activity on account via chosen communication method and opt out or change said method when necessary, so that he / she can receive notifications pertaining to portal dashboard. The portal must provide:
- The ability for a portal user to choose their communication method, email, SMS text or both, for notifications pertaining to their portal dashboard.
- By default, Portal Communication Method is active and set to email.
View / edit non-primary access: A portal user wants to be able to grant (possibly more limited) access for another individual(s) to portal dashboard, so that they can manage the program services together (e.g. two parents on one account). For clarity, we shall refer to this individual as the non-primary client. The portal must provide:
- The ability for the portal user to grant/revoke access for non-primary clients. Depending on the program, access for each non-primary client may differ.
- The ability to time-bound (to/from date) the portal access of each non-primary client.
- The ability for a Program B portal user to grant/revoke access for the non-primary clients to messaging and documents management in their dashboard.
View / edit account information: A portal user wants to be able to change contact information via the portal, so that the program areas has up-to-date information on file. The portal must provide:
- The ability for a portal user to change designated contact information (address, for instance) within the portal, and for the program area to be notified and/or require approval prior to changes to specific elements of contact.
Deactivate portal account: A portal user wants to be able to unregister for services, so that he / she doesn't receive services through the portal and/or the program anymore.
4. Application Submission Process
Through the application process, a user should be able to apply for new child program services through the portal so that he/she can receive program services and manage services online. Please develop your wireframes and user interaction flow to create the best user experience for the application process, it should be intuitive and clear for new users to navigate. The following are the key portal user stories which must be covered by the application process:
- Save and resume an unsubmitted application, so that users do not have to re-start the application process
- Edit a submitted application, so that user can update information prior to the program area working on it
- Delete a submitted application, because user no longer wish to apply for services, so that user doesn’t submit unneeded applications.
- Cancel an in progress application, so that user can withdraw application for services.
- Leverage previous submissions, so that user does not have to re-enter/supply redundant information.
- View historical submissions information, so that user has a complete record of all submissions made for services.
- View all communication between user and the program area that has been conducted through the portal
Key Requirements for the Application Process (see attached documentation for additional details):
- The ability for the application process to provide a guided, intuitive format, along with explanatory text and help/support functions.
- The ability to indicate mandatory fields to the portal user, as well as non-editable information.
- The ability to help orientate the portal user to where they are in the application process (i.e. progress bar).
- The ability to present the portal user with a listing of required documentation that needs to be submitted with an application, based on the answers captured during the application process.
- The ability for a portal user to electronically sign their application prior to submission.
- The ability for an application submitted through the portal, in "Submitted" status, to be recalled by the portal user and edited, if business rules allow.
- The ability for an application submitted through the portal, in "Submitted" status, to be recalled by the portal user and deleted, if business rules allow.
- The ability for an application submitted through the portal, in "In Progress" status, to be cancelled by the portal user through a portal request.
- Once a submitted application is being worked on in the primary database system, the application is locked on the portal and no further changes can be made by the portal user.
Additionally, the application for services (e.g. care) should include the following information:
-- Applicant Contact Information is general contact information (name, address, phone, etc.)
-- Applicant Status (Resident, Proof of Status) – this is a public government program so this is applicant’s proof of residency.
-- Applicant Need for Care (Days and Times for Care) is the demonstrated need for child care (days of the week + times that a child would need care)
-- Applicant Marital Status Information (Spousal Information) is married, single, divorced, etc.
-- Spouse's Need for Care is the same information as provided by the applicant - days and times that the spouse's schedule would require child care
-- Income Information
-- Care Recipient Information is the information for the child receiving care (name, birthdate, school information, allergies, special needs, etc.)
-- Dependent Information (Dependents supported by the household)
-- Declaration is the electronic signature block (includes confirmation of information and consent to disclose)
The applicant should also attach* the following documentation to his / her application for services:
- Proof of Status
- Proof of Employment (Pay Slips or Proof of Self-Employment)
- Proof of Registration for Educational Institution (if applicable)
- Proof of Medical Condition (if applicable)
- Proof of Government Disability (if applicable)
- Spousal Identification (Government Issued)
- Care Recipient(s) Identification (Government Issued)
*Note that there are a specific set of requirements for document uploads and document management. Please refer to “9. Document Management Process” below.
5. Application Renewal Process
For those users who have already submitted an application for services and have received services - the application renewal process should also be able to be managed and performed through the portal. Please consider the best way to include the following use cases in your wireframes:
- A portal user wants to receive reminders prior to renewal being due, so that he / she can renew program application (including required documentation) or status in a timely manner.
- A portal user wants to be able to renew expired application on the portal, so that program services continue.
6. View Services Summary Information
View Services Summary: A portal user wants to view services summary, so that he/she has current services information. The services summary should display the following information:
- Yearly Services Amount (amount of funding/services awarded)
- Current and Previous Year Services disbursement Information
- Available Services Balance
Inquire on Services Summary: A portal user wants to be able to make an inquiry about services summary through the portal, so that he / she can resolve a question.
7. Submission and Communication Process
A portal user should be able to send and receive general and specific messages and requests through the portal. This messaging process may be initiated on its own, based on a specific request from a user, or this may be triggered by another portal activity (such as updating certain account information. For this wireframe challenge the messaging scope is restricted to the general messaging processes for the portal. This includes:
- A portal user wants to send a general message to the business area, so that he / she can initiate a conversation.
- A portal user wants to send a request to the business area, so that he / she can initiate an action on his / her case.
Key Requirements for Submission and Communication Process (please refer to attached documentation for additional details):
- The ability for a portal user to communicate with a program area regarding a general question around their program services
- The ability for a portal user to request a cancellation of their request with a status of "In Progress"
8. Document Management Process
It is important to note that the document management process is a supportive process for other processes, such as the application and renewal processes. For example - the user should be able to upload documents and submit them as part of an application for services. As you analyze the problem and think through the user interactions with the client portal, please use your expertise to incorporate document mgmt where it is appropriate in the designs.
Key Requirements for Document Management (see attached documentation for additional details):
- The ability to upload documents and photos to the portal.
- The ability to attach documents and photos to an application or message in the portal
- The ability to save locally and to print (in printer friendly format) documents, photos, applications and forms accessible through the portal
- The ability for the portal user to manage/filter the documents and photos they see in their portal view
- By default, Portal Documents will show current and last year activity (2 years backward facing) on a case. (older historical submissions should be viewable by the user through adjusting view settings.)
Notes on Attached Documentation
- The attached documentation includes process diagrams, user stories, functional requirements, business rules, and other supporting details for this project.
- Please note that the out-of-scope user stories and requirements have been “grayed” out to indicate they they are not in scope for this wireframe challenge. However, they have been left for your reference as this is helpful context for understanding information flow / details.
Wireframe Expectations:
- Produce HTML click through wireframes that can be used to demonstrate all mentioned functionalities as required in each round.
- The wireframe must be very easy to use and intuitive. Keep that in mind when designing your solution.
- You MUST cover all screens mentioned in required sections below, if any requirement is missing in final submission the client will not look at it, so make a checklist for the required screens to make sure you designed all of them.
- Please show us your proposal as a movie or series of wireframes that communicate the user’s intended interaction with your proposed solution.
- You MUST use wireframes note pane in every single page you design to explain what items are addressed in that page from the documentation, what things you added/changed/removed, use it to make your idea clearer and help the client to give you constructive feedback.
Target Devices
- Desktop : Width 1024px (height can expand as needed)
Target User
- This challenge will focus on a portal client user (referred to in attached documentation as "PU"). Portal users are primarily parents with children under 18
-- Although the Requirements document references additional Business User ("BU") stories, this challeng will focus on the client use cases.
-- The requirements documentation has left the business user information and other out-of scope requirements in for your reference as this is helpful context for understanding information flow / details.
Learn Axure:
New to Axure? Here are some quick tutorials to help you get started.
http://www.axure.com/learn
Judging Criteria
- Overall User Experience
- Completeness and accuracy of the wireframe as defined in the challenge spec
- How well your wireframes provide a consistent user flow.
- How well your wireframe captures all the functionality.
- Any suggestions, interactions and user flows you recommend (provide any notes or comments for the client).
Submission and Source Files
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
All requested contest requirements as clickable HTML files generated by Axure. All the content must be listed and the pages are linked together to show page flow.
Source Files
- Wireframes should be built in Axure. The resulting source files used to generate the clickable HTML files.
- All the content must be listed and the pages are linked together to show page flow.
- All fully editable original source files of the submitted wireframe as required by the contest under "Source Files" in the sidebar should be included in your Source zip file.
Final Fixes
As part of the final fixes phase you may be asked to modify content or user click paths.
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.