While interviewing with Advanced Health and Care, I was asked to complete a simple redesign task in order to 1.) review my design process, and 2.) See a practical example of my HTML5, CSS3 and Javascript skills.


The Task

The task was to redesign a simple form (see below). The interviewers emphasised that I should use this opportunity to detail my design process, and include any UX deliverables (wireframes, user journeys etc.).




I was given the following requirements specification:

  • The form was aimed at ‘general’ users. 
  • Clicking on the ‘Show Summary’ button at the bottom of the page will take you to a page showing a summary of the details inputted by the user.
  • Ensure that the form retains the same type of data, although the method and implementation of data input can change.
  • Fix any broken functionality.

I was given a fews days to complete the task.


Design Process

Below I describe the design process that I went through, my thoughts during the process, and the steps I took.


First Hand Information

The design process started the second my interviewers started talking about the task. At the close of the interview, my interviewers told me they had emailed me a word document and some materials describing the task. My consultant instincts immediately kicked in and I asked them if they could spare a few minutes to go over the particulars of the task.

I cannot stress enough the importance of first hand information. There are many subtle nuances that you will capture when talking to someone (through tone, body language etc.) that will help you establish the parameters of a project. Text can be misinterpreted easily and in the world of digital consulting that can be the deciding factor between securing a new client or not.

I started with the usual questions:

  • Could you give a brief description of the project?
  • Who is the target user for this form?
  • What is the objectives of this assessment? (What skills should I highlight?)
  • What are the deliverables for this project?
  • What is the time frame for this project?

One thing that I learned very quickly, that was not written in the specification was that they wanted me to pay special attention to my use of HTML5, CSS and Javascript, as front-end would play a part in the job, should I get the position. This little piece of information allowed me to adapt my usual design process to meet their objectives.

The initial requirements gathering phase, was followed up later with an email to clarify a couple of points.



The project was deliberately quite open-ended, both in terms of specification and deliverables. I started by building my own little project specification:

  • Target User: I decided to make medical patients the target user for this interface, if only so that I could keep a consistent outlook on the design, copy and functionality. I followed up with the client to ensure that this would fit within the project parameters. 
  • Deliverables: Given the limited timeframe, I had to restrict myself as to what I worked on. I settled on, producing the following:
    • Wireframes show the landing page and summary page.
    • A mockup to use as a guideline for how to style the prototype.
    • A working prototype, written in HTML5, and utilising some nifty technologies (LESS, JQuery and off course some new HTML5 features) to show that I was a capable front-end designer.

As I mentioned, this is a modification of my usual design process. Some activities that I did not have time to carry out were:

  • Research: The usual first step is to look at what other people have done. I spent an hour refreshing myself on the essentials of form design courtesy of A List Apart’s Luke Wrobleski, and had a quick look at few sign up form examples. Ideally, I would have done research into clinical sign up forms, to see if there were any particulars that I needed to know about the area.
  • Client Feedback: Usually after completing some wireframes I find it is very important to have a review meeting, to discuss how the client feels about the layout and functionality, and to check whether I am going in the right direction. Try and do this in-person if possible, I find it it is much easier for clients to describe issues they have with your designs when they can draw, point, and gesticulate at you.
  • Rough prototype: Usually, I like to do a very quick, un-styled clickable prototype (using Omingraffle, Axure or plain HTML), which the client can play around with. This gives them a more solid understanding of how the web page/website with operate in real life.
  • Guerrilla User Testing: It is always a good idea to run even a little bit of informal user testing on an interface, even for such a simple project as this. I would focus on two tasks:
    • Competitors: Observing users performing tasks on similar web pages / interfaces built by competitors can provide interesting insights and sometimes inspire new ideas for features.
    • Rough prototype: Once a rough prototype had been drawn up, I would run users through it to get a feel for whether I was missing any major pieces of functionality. 



Below are the wireframes that I designed. This is the landing page:



And this is the summary page:


You can download the PDF files here:    index.pdf   summary.pdf




This is a design that I made as a guideline for the prototype:


You can download the PDF file from here: design.pdf



The HTML5 prototype can be seen here:


A few interesting things to note about the prototype are:

  • Browser compatibility: I tested the website across Chrome (PC/Mac), Firefox (PC/Mac), Safari and Internet Explorer 8 (I do not have access to IE9/IE10). The only issue is that I did not have time to implement transparent backgrounds in IE8, so it is a flat white for the moment.
  • HTML5: I tried to implement a few of the new HTML5 functionality:

    • Session storage: I used this to user details and then retrieved them for display in the summary page.
    • Date picker: I first tried to use the new date picker control, but after realising it was not compatible with IE8, I decided to switch to a JQuery date picker that worked cross-browser.
    • Form validation: I started using HTML5 form validation, but I found that JQuery’s validation plug-in gave very nice ‘on-the-fly validation’ functionality. I modified it slightly so that it does the validation check ‘on blur’ (as you leave the field) to stop it from flashing red text every time a user selected an input. For a good example of this try typing in an email address without an ‘@’ symbol, and then move to another input.
  • Validation: I have setup both on-the-fly validation and validation on submission, so the user cannot save their data until all mandatory fields have been completed.
  • LESS: I used the LESS plug-in to write my CSS. For those who have never used it, it is truely fantastic, allowing you to use variables and includes inside your CSS file.


The HTML and CSS source files can be downloaded from here: to_ahc.zip

In Review

Due to the time constraints there were a number of things that I would have done differently. I have listed these below:

  • Multi-channel design: The pages have not been optimised for Mobile/Responsive design. Given more time, I would like to develop a mobile-only and tablet-only version, and test it across both iOS and android devices. I know some people advocate mobile first design methodologies, and that might have been an interesting way to tackle the problem.
  • Transparency: I would setup the transparent background for for Internet Explorer 8
  • Form Element Styling: I would style the input boxes and other form elements more closely to the mockup
  • Date picker validation: The original HTML5 date picker did not need validation, as the user could only edit the date via the controls. When I changed over to a JQuery date picker, I had not time to investigate a validator for the date picker.
  • Return to top: For smaller screens, I felt it would be useful to have a a floating ‘return to the top’ button, which only appeared once the user had left the top of the page.
  • Design: If you compare the mockup and the prototype, you will notice that there are some CSS differences, for example, the prototype is missing tick/cross icons for when the a user completes an input and validation is checked. I would add this functionality to the prototype.
  • Saving data: I would setup the the summary page so that you can save the data.
  • Edit all: I would setup the ‘Edit all’ button, which opened all the sections in the summary page for editing at the same time.