A Web Designer's portfolio

A series of drawings of Darryl showing his design and development process. 

The drawings were done using Adobe Draw, on the iPad Pro.

Show me where it hurts

Show me where it hurts

Show me where it hurts was a research project looking at how those with severe speech and physical impairments could use technology to effectively communicate pain to a doctor.  During this study I worked with a GP, several users with cerebral palsy (with varying degrees of severity) and their carers to develop a concept that could make a trip to the doctor a little less painful. Background “GP staff often struggle to communicate with people with communication disabilities, particularly if they do not know them well, and tend to rely on carers.”  Experiences of pain are internal, unique and can be shaped by a number of psychological and physiological factors. As such, it can be difficult to express and assess pain on an objective, universal scale. Medical professionals commonly assess pain using the SOCRATES model, which collects information about the Site, Onset, Character, Radiation, Associations, Time, Exacerbating Factors and Severity of the pain. For patients with severe speech and physical impairments, accurately describing pain can be more challenging due to impairments affecting the ability to communicate. In these situations, patients with SSPIs often communicate through a mediating support worker (diminishing the privacy between patient and medical professional), or an Augmentative and Alternative Communication (AAC) device that the medical professional may have no training or experience with.  The Prototype Several iterations of prototypes covering different technologies and methods for identifying pain. Each prototype was put under the scrutiny of the resident cerebral palsy user testing group at the University of Dundee. With a short period of time, at was more effective to create a low-fidelity video concept to show the result of the research.  The platform: A tablet app was decided as the best platform for the application. The doctor's surgery would own the device. Alternative options, such as having an app the patient could track changes in their condition were also considered by the researchers and the user group. This was the best option for all.  Tap size and recovery: No need to be accurate, the patient can tap/hit anywhere on the screen. The countdown gives them the opportunity to make changes, if they were to tap the screen at the wrong time. the countdown does seem very long. But for our participants, any less time caused anxiety. Pain location: Starting with blocking out areas of the body and asking the patient more specific location questions as they go means that a fairly accurate location of the pain can be obtained very quickly. However, one area for improvement would be to identify the source of the pain or the worst pain, if the pain were all over the body. Type of pain: Icons to describe types of pain went through several iterations to ensure that each icon described the same type of pain for patient, the carer and the doctor. The focus groups on this were great fun. Pain intensity: Using the traditional 1-5 scale. This is instantly recognisable. Future iterations would cover if 1-5 were enough.  The rest of the SOCRATES pain model: Unfortunately, this is as far as the project went. However, a more full solution would cover all 8 factors of the pain model.  

Make Studying Fun

Make Studying Fun

Following a user-centred design methodology, a prototype mobile game concept was built to bring current mobile-gaming trends into secondary education. Background Game theory and design is an area that is seeing more and more academic research. Electronic gaming has changed considerably over the last few years, so have the platforms these games are played on. However, the educational games we find in app stores and classrooms for teenagers could be described as little more than “chocolate-covered broccoli” During the project I worked collaboratively with secondary school students to create prototypes. These ranged from low-fidelity sketches to a web-based application. The game The end game combined the goals of the teachers we spoke to. A reminder of the day's class Did not need to be manually graded Could show how well a student had understood a topic Could identify students that need extra help And different goals from the student: should be fun able to do while watching tv, on the bus... see how I compare with others (without them seeing my scores) The end result was a quick-fire quiz style game. The teacher could set questions from their lesson. Students would need to concentrate intensely for each short round but would be free to leave and return to the game at any time. Students are encouraged by rewards (stars) and seeing a leaderboard of their classmates scores (not their classmates names) as extra incentive to keep playing. The teacher can get an understanding of how students are doing and identify knowledge gaps in individuals and groups. this can then inform real-world incentives and even the classroom seat plan. A series of short, medium and long term goalsPlayer control, a player must have to make decisions that affect the gameplayImmediate and specific feedback to the userA reward system/sTeaching aspects for the longer goalsVarying skill levelsA player should not be led by the hand throughout the entire game The prototype The screen part of the web-application prototype (made using jQuery and PHP.) is an iframe, when the iframe page is loaded by itself it shall scale to the size of a user's device. This allowed me to gain feedback about a mobile application quiz from multiple users of both personal computers and mobile devices.  When the page loads the progress bar starts moving. When it gets a third of the way along, the colour changes from green to amber and the first hint is shown. After the bar is two thirds of the way along it changes from amber to red and a final hint is shown.