Presumptions.

I pressumed that all content is there for a reason, e.g. last updated date has been requested by users. Therefore unless specified for a particular reason, I kept all information that was present on the current dashboard. Please see further considerations below for how this might be streamlined.

Design Considerations.

I have used roboto font throughout my design instead of trying to replicate the font.

I used an 18 column grid with 40px margins and 20px gutters.

Any alterations I made to shade, I checked that the change in contrast between the font colour and new background colour still falls within the Web Content Accessibility Guidelines (WCAG) ratio and are therefore still easy to read.

Banner.

Alert: Changed to a neutral colour from red for “no new alerts” so that the user’s attention is not drawn there unnecessarily. Moved the location of the indicator further up so that the shape of the bell was not obscured.

Time stamp: Removed the seconds value as that level of detail is not required, this is consistent for all time stamps across the dashboard.

Tabs/ Table Header.

Initially, I thought that the “Tasks” tab was active as it matched the side menu highlight and the outline around the “Patient Requests” tab cuts it off from the table header indicating that it is inactive.

So I changed the colour of the active tab and header of the table to match the highlight colour of the side menu for consistency.

Changed from a solid red to red outline to show number of requests and tasks. Although it needs to be highlighted, it is not an actual call to action, so this is a happy medium. This would also be how any alerts would be shown.

Table Content.

Increased the font size slightly for ease of reading.

Changed the “Name” format so that the surname is first and in caps. This allows for no ambiguity in name and also allows the table to be arranged in surname order which is more useful than forename.

For “Indication” and “Status”, I spread over 2 lines so that it is easier to visually differentiate the primary value, e.g. “Medical” and the secondary value e.g. “Simple Query”.

Added an option to arrange results by value for “Indication”. This was the only table value that didn’t have this option, users may like to view all similar requests in one batch.

Originally the shape of the highlight given to the “Status” gives the appearance of a button. The green colour contradicts the written “Action Required” status, especially when considered with the traffic light system used in the neighbouring panel. Instead I used a red square to highlight to the user that action is required.

Buttons.

Primary Buttons: Classed Filter and Actions as primary buttons, changed the font to all caps to stand out as a call to action.

Filter: Changed the name from “Filters” to the conventional “Filter”. Moved the icon to the right so there is consistency across primary buttons. Amended dimensions and centre aligned with the search text box so that it visually sits better (was previously top aligned).

Actions: Red draws the attention in a more urgent way than required. Changed colour for consistency across primary buttons.

Help: Originally alone in style and format. I grouped with the buttons used in the side menu and classed these secondary buttons as “guidance” and amended the size/style accordingly.

Button Removal.

I removed the “Action” drop down from the table as it is too similar to the “Actions” button close by.

I would combine all options together under one. This was one of the hardest decisions to make, the cons being that they may not have the same functions intended and to access only via the side panel, means an extra click for the user to get there.

However the last point is also a safety net; when concentration is not optimal, it would be easy for a user to look at data from the side panel and correlate it with a patient that is not selected from the table due to the proximity. By adding the extra step, any actions decided on are for the correct patient.

Side Panel.

It is not imediately clear that the right side panel shows information for a patient selected from the table. The emphasis given to the “Patient Requests” tab via a bold outline takes away from the selected patient’s less bold outline.

I increased the thickness of the outline on the selected patient and made the colour fill darker by a few shades. Finally I made the font bold to standout further. I matched this style on the right-hand panel to show that they are linked.

In the white text box, I made the patient details bold so that they stand out more than the prompts.

Traffic Light System.

Although I really enjoy the traffic light system to highlight areas of concern, in order to prevent them looking too much like buttons and also to give the amber and red more importance, I used a lighter shade fill and kept the outline darker. For amber the outline is bold and for red, it is bolder still.

I moved the information over two lines as I noticed that the severity reading 6/10 ended up being split. This makes reading the results easier.

Review of the naming convention:

On the banner, information is given to the user regarding the number of reviews, tasks and requests. Although tasks and requests are visible via the tabs on the dashboard, it is unclear where reviews are located and therefore what they cover.

There is some overlap with similar phrases: action required, actionable, actions. Mapping out pathways and tasks would be a good way to find out if there are other phrases that are clearer to use.

Replication of information/ Streamline the information given:

As the number of tasks and requests is visible on the tabs, it is worth reviewing if it is also required on the banner.

There is replication of patient information in the table and side panel. An alternative to having a side panel at all would be to have all the extra information appear as a drop down. However I feel that this could potentially make it overly complicated, it would be better tackled as part of a larger project to review what information is given on the dashboard and what is actually needed.

Search Function:

To make it clear for users, a prompt above the search box would identify what parameters can be searched for.

Scroll Bar:

Adding a scroll bar (and keeping the table header static) would help users when they have a longer list of patients/ tasks.

Breakpoints:

Being aware of the different size screens users would be viewing the application on and therefore identifying any breakpoints to be designed around. For example, for a narrow screen desktop or tablet, the side bar menu would be better as a pop out menu to allow better use of space.

Flat Style:

I maintained the original flat style, therefore I added no shadows to buttons etc. However a subtle addition to help users identify buttons and to add depth to the page could improve the feel.