Challenge Summary
Welcome to Quartz - Well Log Alignment Webapp Concept Design Challenge.
We need your wise UX design skills to tackle down an interesting data visualization challenge. Our client is developing a smart tool that compares two sets of data, finds errors automatically and offers a way to fix them through a guidance process.
Best of luck.
2. Projects
4. Remediation
- Please provide a MarvelApp Presentation (see details below).
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
1. Login
2. Projects
3. Load Files To Project
4. Remediation
- Please provide a MarvelApp Presentation (see details below).
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
The goal of this competition is to come up with the look and feel of a web application for the oil & gas industry that will help users to solve log conflicts in an intuitive fashion.
Design Problem In A Nutshell
Background
In the oil and gas industry, geologists collect extensive information from the drilling and exploration process. This information is collected and analyzed through a series of log files which the geoscientist can review.
In this sample, you can see an image which displays a typical set up of a drill string with a set of instruments. Each of the instruments shown in that figure generates a series of readings which are captured in a set of log files (FYI, called .LAS log files).
Errors
There could be errors happening on these log files due to the fact that different instruments could be delivering data at different granularity, the instruments themselves are placed at different locations along the drill string, and there are failures that occur with the instruments themselves.
Log Alignment (Fix Errors)
After the data is captured, a geophysicist looks at all these log files and goes through a process of remediating the logs so they tell a consistent story about what’s really happening in the well (fix errors).
The log files are all depth registered. There are often obvious relationships between the log files but because of errors in the depths, the relationships will break down.
In this sample, we display a typical manual adjustment of the log files (how it would look):
A. The RHOB log provides density readings.
B. The DP logs provides sonic data.
C. The DP_SH figure shows the DP data (B) after it has been shifted up manually by the user so that it matches the features in the RHOB data (A) more precisely. SH suffix stands for shifted (fixed).
Solution
We’re developing a tool that will be able to identify and automate these adjustments; basically, to read the log files, analyze them, detect the errors and then have a UI where the user can remediate (fix/align) the log sections that have errors step by step. We are trying to correct the errors in the depth alignments between the readings of different instruments.
On this design exercise, we expect you to come up with a solution that allows the users to remediate these logs differences - to align events in one log to the events in another log - in an very easy and intuitive manner.
Concept Design Goals
The design solution should solve the design problem while considering the following key features:
1. User must be able to quickly identify the errors.
2. User should be able manually connect event in one log to the event in another log and see the results of the adjustment right away.
3. Give an option to “snap” user manual picks to local maxima/minima of the log to make sure we aligning maximum energy.
The style should be very clean, professional, well spaced, with good contrast for graphical elements and controls. This is basically a tool so we don't want distracting widgets and colors.
The provided sample is a very rough mockup used to explain how the data series (columns) work. We DO NOT WANT to see a skinned version out of the sample, there should be dozens of ways to represent the requirements in a better fashion.
Screens Requirements
Overall
- Show hover/active states for buttons, dropdowns, breadcrumbs, errors/success states, elements with interaction, etc.
- Please suggest how to organize this content and group them into screens, we are looking forward to seeing your unique proposals, be bold. The following screens orders are just initial suggestions but we think content could be organized in a different way, go for it!
1. Login
User is able to login with basic data:
- Email
- Password.
Add an option to remember the user for the next session.
2. Projects
User can create, edit, delete projects. A project is basically a holder of LAS files related to a specific well, meaning that it is a one-to-one relationship, project-1-well. Typically, the project data would be the following:
- Name (well name).
- UWI (unique well identifier).
- APIN (API Number).
- Field.
- Latitude/Longitude Information.
- Well Operator: company running the well.
- LAS Files: set of uploaded files related to the project.
User can view log files and details associated to a project (details view). There are sample LAS files attached.
3. Load Files To Project
User should be able to load datasets to the system (sensor readings - .LAS files), one or multiple files at a time. This action could be performed from the project details page or from a separate page, we are open to suggestions according to what suits best UX wise.
After a successful upload, the user should be allowed to perform the following actions:
- See what data series are available within the file. There could be from two or ten columns of data in the result coming from the file reading.
- User should be able to see 2-10 amount of detected columns in the form of charts with some useful insight data e.g. well name, amount of columns, possible errors (if any), etc.
- From this point the user can confirm the data or select to perform a remediation/fix.
Files Logic - Link
This is not a feature, just further explanation about how the files work. It’s not mandatory to read but if you want to understand the big picture don’t hesitate to follow this section. Don’t let the length and oil industry slang intimidate you, it’s not rocket science.
- Files will always contain three columns: Depth (common for all sensors), Sensor A and Sensor B.
- ~A: just a placeholder, ignore (it indicates the start of a table - it doesn’t have any impact in the UI).
- DEPTH: depth of the well bore, all file logs share the depth data (Y axis).
- Ignore depth values registered as -999.0000 (not valid - not displayed).
WELL6.LAS:
- This is the file seen in the sample from the Design Problem section.
- DT_to_sh: DT is sonic measurement. This is the secondary data series in this file (to be shifted/fixed, as in the mentioned sample).
- RHOB_ref: RHOB is a bulk density measurement. This is primary measurement in the data series.
DT_to_RHOB_shift.LAS:
- GR: Gamma Ray Responsivity measurement.
- RESD: Resistivity - Measures inverse of the conductivity of the rocks.
X-axis:
Not mentioned in the files, but you should know these units so you can represent them on the x-axis of the charts.
DT: 40-140 micro sec/ft.
RHOB: 1.65-2.65 g/cc.
GR: 0-150 API.
Resistivity: 0.2-2000 ohm.
4. Remediation (Log Alignment)
This is the cornerstone of the tool. This screen should take the user through the log fix process. This action could be performed from the Load Files page or from a separate page, we are open to suggestions according to what suits best UX wise.
The following features must be represented on this scenario:
- Select which .LAS file is going to be analyzed (list of LAS files).
- Display two charts side by side in graphical form. User should be able to select which data he/she wishes to preview/see within each sided chart (columns from the LAS files, there could be 2 or 10 to choose from).
- Allow the user choose which data series (column) is the primary (reference) one. This would correspond to the A column from the sample (RHOB).
- Allow the user choose which data series is the secondary one which will be shifted. This would correspond to the B column from the sample (DP).
- The secondary data set will be shifted up or down by the user to match the features in the primary data series.
- User has a mechanism to shift the data (same secondary column in a new third column/view) manually to match the readings from the reference/primary column.
- The application should visually identify where the logs seem to be in sync and where they don't seem to be in sync (in sync: match up at the same depth). There could be from a few to hundreds of mismatches, so plan how to allocate such an amount of records and help the user keep engaged through the process.
- Wherever there is a mismatch (out of sync), it should be highlighted in both charts, the third one would allow to modify the value manually. Meaning that the user should have a mechanism to adjust the mismatching values, either by manually entering the value for certain point (s) or moving/dragging the peaks/troughs. This is a forward cycle for every mismatching information (next/prev/confirm).
- Charts should be easy to navigate, having features such as zoom (in/out), horizontal/vertical panning, etc.
- Snap to grid type features to allow users to easily align large features (if moving peaks with dragging). Snap to grid should be able to turn on/off. See sample of the feature, how an adjustable/draggable item can stick/snap to certain predefined positions in a grid.
- After the user finished editing and adjusting all the mismatches, there should be a mechanism to end the process, a confirmation (probably a button). Once this confirmation is activated, a dialog should show up with a success message and download the fixed .LAS file which contains the adjusted data.
Alignment Tool Deliverables
Please create the necessary amount of pages to display the workflow of this interesting interactive tool. We expect at least to receive the following screens (but you are encouraged to display more in order to not leaving room for imagination when explaining your concept):
1. Three columns view.
2. Setting primary/secondary columns process.
3. Charts with at least 10 out of sync records (or however you decide to represent the mismatches).
4. User navigates through each mismatching record and adjusts the values.
5. Chart interaction samples for zoom and panning.
6. Final confirmation dialog (success).
** Minimum 7 screens to showcase all this process, but again, encouraged to develop more.
Branding Guidelines
- Use a logo placeholder.
- Color preferences are blues on #006BD5, light grays and whites. Open to suggestions but keep blue as primary brand.
- Fonts open to suggestion.
- Keep things consistent. This means all graphics styles should work together.
Screen Specifications
- Desktop: 1280px width. Height as much as needed.
- Make sure your work is in a vector format, for retina scaling and high fidelity.
MarvelApp Presentation
- Request a MarvelApp prototype from me (mahestro@copilots.topcoder.com).
- Do not use the forums to request for MarvelApp.
- Provide clickable spots (hotzones) to link your screens and showcase the flow of the solution.
- Provide the MarvelApp shareable link in your notes during submission upload.
Stock Artwork (Illustrations, Icons, Photography)
- Stock artwork is allowed for this challenge.
- Make sure to declare all your assets properly or you might fail screening.
Target User
Geophysicist and Geologists from the Oil Exploration industry. Very comfortable experienced persons using web applications, software is a part of their daily lives. They live in data-driven applications and statistics. They use a fairly sophisticated suite of tools to perform their daily work. We're hoping to supplement their toolset.
Judging Criteria
- Is the conflict resolution process easy to learn and use?
- Completeness of the requirements.
- Interpretation of the user experience.
- Is the application visually appealing?
- Cleanliness of your graphics and design.
Submission & 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
Submit JPG/PNG for your submission files.
Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop, Illustrator or Sketch. Layers should be named and well organized.
Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback.
We need your wise UX design skills to tackle down an interesting data visualization challenge. Our client is developing a smart tool that compares two sets of data, finds errors automatically and offers a way to fix them through a guidance process.
Best of luck.
Round 1
Submit your design for a checkpoint feedback.2. Projects
4. Remediation
- Please provide a MarvelApp Presentation (see details below).
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
Round 2
Submit your final design plus checkpoint feedback.1. Login
2. Projects
3. Load Files To Project
4. Remediation
- Please provide a MarvelApp Presentation (see details below).
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).
The goal of this competition is to come up with the look and feel of a web application for the oil & gas industry that will help users to solve log conflicts in an intuitive fashion.
Design Problem In A Nutshell
Background
In the oil and gas industry, geologists collect extensive information from the drilling and exploration process. This information is collected and analyzed through a series of log files which the geoscientist can review.
In this sample, you can see an image which displays a typical set up of a drill string with a set of instruments. Each of the instruments shown in that figure generates a series of readings which are captured in a set of log files (FYI, called .LAS log files).
Errors
There could be errors happening on these log files due to the fact that different instruments could be delivering data at different granularity, the instruments themselves are placed at different locations along the drill string, and there are failures that occur with the instruments themselves.
Log Alignment (Fix Errors)
After the data is captured, a geophysicist looks at all these log files and goes through a process of remediating the logs so they tell a consistent story about what’s really happening in the well (fix errors).
The log files are all depth registered. There are often obvious relationships between the log files but because of errors in the depths, the relationships will break down.
In this sample, we display a typical manual adjustment of the log files (how it would look):
A. The RHOB log provides density readings.
B. The DP logs provides sonic data.
C. The DP_SH figure shows the DP data (B) after it has been shifted up manually by the user so that it matches the features in the RHOB data (A) more precisely. SH suffix stands for shifted (fixed).
Solution
We’re developing a tool that will be able to identify and automate these adjustments; basically, to read the log files, analyze them, detect the errors and then have a UI where the user can remediate (fix/align) the log sections that have errors step by step. We are trying to correct the errors in the depth alignments between the readings of different instruments.
On this design exercise, we expect you to come up with a solution that allows the users to remediate these logs differences - to align events in one log to the events in another log - in an very easy and intuitive manner.
Concept Design Goals
The design solution should solve the design problem while considering the following key features:
1. User must be able to quickly identify the errors.
2. User should be able manually connect event in one log to the event in another log and see the results of the adjustment right away.
3. Give an option to “snap” user manual picks to local maxima/minima of the log to make sure we aligning maximum energy.
The style should be very clean, professional, well spaced, with good contrast for graphical elements and controls. This is basically a tool so we don't want distracting widgets and colors.
The provided sample is a very rough mockup used to explain how the data series (columns) work. We DO NOT WANT to see a skinned version out of the sample, there should be dozens of ways to represent the requirements in a better fashion.
Screens Requirements
Overall
- Show hover/active states for buttons, dropdowns, breadcrumbs, errors/success states, elements with interaction, etc.
- Please suggest how to organize this content and group them into screens, we are looking forward to seeing your unique proposals, be bold. The following screens orders are just initial suggestions but we think content could be organized in a different way, go for it!
1. Login
User is able to login with basic data:
- Password.
Add an option to remember the user for the next session.
2. Projects
User can create, edit, delete projects. A project is basically a holder of LAS files related to a specific well, meaning that it is a one-to-one relationship, project-1-well. Typically, the project data would be the following:
- Name (well name).
- UWI (unique well identifier).
- APIN (API Number).
- Field.
- Latitude/Longitude Information.
- Well Operator: company running the well.
- LAS Files: set of uploaded files related to the project.
User can view log files and details associated to a project (details view). There are sample LAS files attached.
3. Load Files To Project
User should be able to load datasets to the system (sensor readings - .LAS files), one or multiple files at a time. This action could be performed from the project details page or from a separate page, we are open to suggestions according to what suits best UX wise.
After a successful upload, the user should be allowed to perform the following actions:
- See what data series are available within the file. There could be from two or ten columns of data in the result coming from the file reading.
- User should be able to see 2-10 amount of detected columns in the form of charts with some useful insight data e.g. well name, amount of columns, possible errors (if any), etc.
- From this point the user can confirm the data or select to perform a remediation/fix.
Files Logic - Link
This is not a feature, just further explanation about how the files work. It’s not mandatory to read but if you want to understand the big picture don’t hesitate to follow this section. Don’t let the length and oil industry slang intimidate you, it’s not rocket science.
- Files will always contain three columns: Depth (common for all sensors), Sensor A and Sensor B.
- ~A: just a placeholder, ignore (it indicates the start of a table - it doesn’t have any impact in the UI).
- DEPTH: depth of the well bore, all file logs share the depth data (Y axis).
- Ignore depth values registered as -999.0000 (not valid - not displayed).
WELL6.LAS:
- This is the file seen in the sample from the Design Problem section.
- DT_to_sh: DT is sonic measurement. This is the secondary data series in this file (to be shifted/fixed, as in the mentioned sample).
- RHOB_ref: RHOB is a bulk density measurement. This is primary measurement in the data series.
DT_to_RHOB_shift.LAS:
- GR: Gamma Ray Responsivity measurement.
- RESD: Resistivity - Measures inverse of the conductivity of the rocks.
X-axis:
Not mentioned in the files, but you should know these units so you can represent them on the x-axis of the charts.
DT: 40-140 micro sec/ft.
RHOB: 1.65-2.65 g/cc.
GR: 0-150 API.
Resistivity: 0.2-2000 ohm.
4. Remediation (Log Alignment)
This is the cornerstone of the tool. This screen should take the user through the log fix process. This action could be performed from the Load Files page or from a separate page, we are open to suggestions according to what suits best UX wise.
The following features must be represented on this scenario:
- Select which .LAS file is going to be analyzed (list of LAS files).
- Display two charts side by side in graphical form. User should be able to select which data he/she wishes to preview/see within each sided chart (columns from the LAS files, there could be 2 or 10 to choose from).
- Allow the user choose which data series (column) is the primary (reference) one. This would correspond to the A column from the sample (RHOB).
- Allow the user choose which data series is the secondary one which will be shifted. This would correspond to the B column from the sample (DP).
- The secondary data set will be shifted up or down by the user to match the features in the primary data series.
- User has a mechanism to shift the data (same secondary column in a new third column/view) manually to match the readings from the reference/primary column.
- The application should visually identify where the logs seem to be in sync and where they don't seem to be in sync (in sync: match up at the same depth). There could be from a few to hundreds of mismatches, so plan how to allocate such an amount of records and help the user keep engaged through the process.
- Wherever there is a mismatch (out of sync), it should be highlighted in both charts, the third one would allow to modify the value manually. Meaning that the user should have a mechanism to adjust the mismatching values, either by manually entering the value for certain point (s) or moving/dragging the peaks/troughs. This is a forward cycle for every mismatching information (next/prev/confirm).
- Charts should be easy to navigate, having features such as zoom (in/out), horizontal/vertical panning, etc.
- Snap to grid type features to allow users to easily align large features (if moving peaks with dragging). Snap to grid should be able to turn on/off. See sample of the feature, how an adjustable/draggable item can stick/snap to certain predefined positions in a grid.
- After the user finished editing and adjusting all the mismatches, there should be a mechanism to end the process, a confirmation (probably a button). Once this confirmation is activated, a dialog should show up with a success message and download the fixed .LAS file which contains the adjusted data.
Alignment Tool Deliverables
Please create the necessary amount of pages to display the workflow of this interesting interactive tool. We expect at least to receive the following screens (but you are encouraged to display more in order to not leaving room for imagination when explaining your concept):
1. Three columns view.
2. Setting primary/secondary columns process.
3. Charts with at least 10 out of sync records (or however you decide to represent the mismatches).
4. User navigates through each mismatching record and adjusts the values.
5. Chart interaction samples for zoom and panning.
6. Final confirmation dialog (success).
** Minimum 7 screens to showcase all this process, but again, encouraged to develop more.
Branding Guidelines
- Use a logo placeholder.
- Color preferences are blues on #006BD5, light grays and whites. Open to suggestions but keep blue as primary brand.
- Fonts open to suggestion.
- Keep things consistent. This means all graphics styles should work together.
Screen Specifications
- Desktop: 1280px width. Height as much as needed.
- Make sure your work is in a vector format, for retina scaling and high fidelity.
MarvelApp Presentation
- Request a MarvelApp prototype from me (mahestro@copilots.topcoder.com).
- Do not use the forums to request for MarvelApp.
- Provide clickable spots (hotzones) to link your screens and showcase the flow of the solution.
- Provide the MarvelApp shareable link in your notes during submission upload.
Stock Artwork (Illustrations, Icons, Photography)
- Stock artwork is allowed for this challenge.
- Make sure to declare all your assets properly or you might fail screening.
Target User
Geophysicist and Geologists from the Oil Exploration industry. Very comfortable experienced persons using web applications, software is a part of their daily lives. They live in data-driven applications and statistics. They use a fairly sophisticated suite of tools to perform their daily work. We're hoping to supplement their toolset.
Judging Criteria
- Is the conflict resolution process easy to learn and use?
- Completeness of the requirements.
- Interpretation of the user experience.
- Is the application visually appealing?
- Cleanliness of your graphics and design.
Submission & 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
Submit JPG/PNG for your submission files.
Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop, Illustrator or Sketch. Layers should be named and well organized.
Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback.
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.