I was asked to design an app for a clinical trial. The design needed to record the effects and effectiveness of drugs treating Alzheimer’s disease.
It needed to be able to gather data for every 15 minutes, check for symptoms, including a specific symptom that was being looked for, and only collect data for periods in which the user was awake. It needed to allow the user to input data for the last four hour span, and to take into account that the user might not have fine motor control.
It also needed to be designed for smartphones.
The clickable prototype can be seen here.
Interactive Prototype of one of the projects I worked on at Insightsoftware.com. We were redesigning the Budgeting part of the application, and I built the model with the concept that if required the entire application could be replicated as an interactive prototype at a later date.
It can be found here.
Ramsdens UX recommendations
Snapshot of a partial sprint report (pdf)
Snapshot of a wireframe for a system for talking to analysts about information on global mineral trades (pdf)
Wireframe for setting alerts for trades (pdf)
Partial wireframe showing how international trade information for the global mineral market can be displayed (pdf)
Sketching out how (and why) you might need to define secondary lookups within an ERP database.
Sketching the design of the interface for setting table lookup defaults and overrides.
Sketching out the interface for the design of the filter selection screen for a new report construction tool for a cloud served mobile and desktop ERP reporting application
Sketching out the interface for the design for a new report construction tool for a cloud served mobile and desktop ERP reporting application
Sketching out the charting engine interface for the design for a new report construction tool for a cloud served mobile and desktop ERP reporting application
The following interface is designed to allow the user to define the tables and columns from an ERP database. The table, column, and description are not user defined (if they are custom made, that is done as part of the ERP system, not the reporting tool that is part of) The “Defaults” column informs the user if they are using a default, or if the default value has been overridden in the report they are working on. Everything from the Category Column to the right, is user definable. Everything to the left is read only, and taken from the database. Category is selected via dropdown. The Options column defines the way in which the user wants the information displayed. Selected from dropdowns. If the user wishes to change (or define) a Table Lookup, then they click on the “…” button in the Table Look Up column. This will open a new dialog to define “Table Lookups”
This dialog allows the user to map data from one column, to another. Once a selection has been made in the “Table” list, the “Code Column” list is populated with the appropriate options for the user to select. Once one has been selected, the “Description Column” list is populated. The dialogue proves feedback on your selections by displaying them as text. Sometimes the user will want to display specific values for certain results. e.g. If the table is Meal type (Breakfast), the Code column contains the different food options (French Toast) , the user may need to change the name of French Toast to Biscote. This can be achieved through the “Conditions…” button.
Obviously the dialog is much more powerful, allowing references to other columns, or in the case of numeric data, it allows for Greater than or less than sums, as well as allowing for lists, and the usual comparison expressions.
The user has now saved the definition of the table look up. This is shown as an override. If this only applies to this report, then the user is finished. If however, this override applies to every report that will be generated by the company, the user will need to apply these changes. Every line that has an override will now show a button with a dropdown menu, which has been named “Action” for now. It is located in the right most column, which is for now called “Further Actions” Clicking on “Revert to Default will remove the overrides, and return the row to the default settings. Clicking on “Make Global Default” will cause the override to cease being an override, and become the default across all reports. Further overrides will revert to these new settings when the user clicks on “Revert to Default” in the future. However, it will first confirm the action.
As shown here
Similar to what already existed, the application needed the ability to zoom out, as the number of tables could quickly become impossible to navigate on a typical screen. The removal of a few extraneous UI elements that were taking up screen real estate despite rarely being used helped improve the amount of space to work with, when there were often more than 50 tables there was only so much that could be done.
Designing a clean interface for multiple joins to the same table created some challenges in reducing the amount of visual information involved, but using the visual metaphor of old fashioned phone switchboards for joining the individual entries seemed to provide some interesting possibilities.
Supporting multiple ERP systems did not always allow for the most elegant solutions. However, the most elegant solution supported by all the ERP systems that we supported was for us to create instances of the table. In most cases, the user was going to be an advanced user who would be more than happy with sequential naming of the instances, but certain users (especially those with a mind to minimising the need for extensive documentation) would benefit from the ability to name the table to indicate what usage the instance provided for.