Amanda Koh

Maven Securities Ltd.

Tue, 09 Nov 2021 00:00:00 GMT

MY ROLE

I joined Maven Securities, a proprietary trading firm, as their first User Experience Designer. As part of my role, I design and develop a web-based trading application that aims to replace the third-party software that is currently used. My responsibilities include:

Research, design and build new features
Conduct usability tests and interviews on new designs
Build and maintain internal library of reusable components and design frameworks for rapid prototyping (React, Typescript)
Collaborate with other teams to provide design skill to other engineering teams

The Problem
The Product
My Process
Progress and Challenges
Expanding Design at Maven

THE PROBLEM

As part of Maven’s expansion into the US trading markets, they would be unable to use their current third-party trading software to trade in the US. Instead of trying to find another third-party solution and adapt their internal systems to work with it, it was decided that Maven would build their own version. This would better cater to their traders’ specific needs and integrate better with existing company systems.

THE PRODUCT

The Execution UI is a data-heavy application used to:

buy/sell stock options
monitor the stock market
monitor the state of company trading infrastructure i.e. what trading algorithms are running

Screenshot of current third party solution

MY PROCESS

INITIAL PROTOTYPE

When I joined, a basic prototype had been built to showcase the possibilities of a web application. It provided 1 key function that would be featured in the Execution UI. I used this prototype as a sandbox for my initial design ideas, demonstrating the styling and interaction changes I wanted to introduce to the new Execution UI in a controlled way. I wanted to solicit initial feedback from stakeholders and develop building blocks with which to start designing the full Execution UI.

The prototype I was given to upon joining. Built with Fluent UI components, it was already being used by some traders to toggle different states. A series of interviews with these traders revealed many possible improvements, short and long term. In particular, the hierarchical display of information was very important across all trading applications, but was represented very inconsistently across the existing internal applications

FIRST STEPS

understand how the third-party solution works, what it does and how it is used within Maven
**shadow and conduct user interviews** with traders to understand their workflows
redesign prototype to validate impact of design improvements
extend design to include more features required by Execution UI

An initial redesign of the prototype interface

INITIAL FEEDBACK

I received some unconventional feedback to my redesign that challenged my ideas on how to design good interfaces.

Interactions must be fast BUT minimise human error
- “I want to perform any action in under 2 click”
- “I can’t do anything by mistake, but checking is too slow”
Whitespace is the enemy
- “Everything is too far apart, I want to see as much information as possible onscreen”
Traders want to be expert users
- “I will memorise shortcuts and hotkeys to increase efficiency”
- “I know that menu exists, there’s no need for a button”
Usability ≠ easy to use
- “Good traders need good eysight, make the font smaller”
- “Some things shouldn’t be easy to do, we want to encourage thinking”

RE-EVALUATING MY APPROACH

Immersing myself in the original requirements gathering, notes from observing trader workflows and feedback from the first redesign, I summarised the traders’ priorities as:

Condensed
Fast
Reliable

I used these 3 principles as the focus of all future designs, ensuring they were always addressed.

Updated redesign of the prototype interface

In the updated redesign of the prototype interface. Key changes included:

monospaced font for numbers
condensed rows with odd row highlights
reduce visual clutter i.e. line separators
prioritise information over context

IMPLEMENTATION

Now that I knew what the prototype’s design update would look like, I started to plan out the tech stack for the project. At this point, our first front-end engineer has just joined, and we worked on this together. We wrote up a plan for language and framework choices(React, Typescript), potential library options for important features i.e. React Beautiful DnD, React Grid Layout, AgGrid.

As we settled into our partnership, I took on responsibility for building our component library to match the design system that I had started to flesh out during the prototype redesigns. For this I chose Material UI as a base and used Styled Components to apply styling as required. As development of a production version of the product began, I built the UI elements, i.e. creating layouts, menus and other interface-only interations. Meanwhile, the engineer worked with other engineering teams to ensure that back end services were available to the front end, then where necessary, hooked up the non-functional UI components I built to the appropriate actions.

Looking at the longer term requirements for the product, once the basic template of a modular window UI had been decided, delivery milestones were defined corresponding to each window. While the windows had many shared features i.e. resizable, draggable, table-based. Each module/window had a certain number of unique features, requiring designated design and engineering time. As a team we focused on laying the groundwork, building shared functionality first before starting work on our first window. The idea was, as development continued, window development would speed up as we could build on work done for previous windows.

PROGRESS AND CHALLENGES

At the time of writing, it has been just over a year since I first started at Maven and 9 momnths since we started development work. We have just given our first demo to stakeholders, showcasing 4 of the 7 windows required for a MVP release in 3 - 6 months time.

PERFORMANCE

As a data-heavy application, performance is an important consideration. I work closely with the front-end engineer to ensure that my designs did not place an unnecessary burden on performance. I investigate how best to marry our user’s requirements with performance limitations. For example, user interviews suggested that traders wanted data to update 10 times per second. However, user testing I conducted demonstrated that they realistically could not tell the difference between different update rates past twice per second. This finding significantly eased the performance burden for our application.

CHANGE RESISTANCE

Traders have been using the current third-party solution for a long time. Many traders joined as graduates and have only ever traded using this platform. As the application that they spend most of their day using, it was important that I screen feedback I received for symptoms of a reluctance to change old habits. I noticed that designs that proposed larger changes in their workflow would face stronger criticism. However, they were not unresponsive to my suggestions as long as I could demonstrate they better addressed their priorities (Condensed, Fast, Reliable).

I am fortunate to have the support of leaders in my company, who are invested in improving the quality of their internal web applications. While they have historically been plagued with poor design, janky UI and a hacky code-base,, they have realised, that in an industry where speed is paramount, making UI flows more intuitive and less cluttered will make a difference.

EXPANDING DESIGN AT MAVEN

CREATING CONSISTENCY

When I first joined Maven, I conducted a review of all the UIs built and maintained by the engineering teams. As the first and only designer at Maven, I was often consulted by these teams for design feedback. This made it clear to me that my role was the perfect opportunity to address the lack of consistency across Maven UIs. I introduced the concept of a company-wide component library so that internal applications could have a more consistent look and feel. It would also reduce the need for front-end skill across different engineering teams, which was lacking.

As part of my Exeuction UI project, I am building a component library, which upon completion will be made available to all engineering teams for them to use on future web application development.

CONSOLIDATING STANDARDS

In addition to consistency in the UI, I noticed that the display of data across trading teams and applications were inconsistent. The same field would have different abbreviations and be highlighted different colours. As this product, the Execution UI, will be used by all trading teams and consolidate functionality currently provided by multiple trading applications, it was a great opportunity to standardise conventions for displaying data.

I liased with each trading team to define a set of shared conventions that worked for everyone and am working on integrating them into the UI. These conventions are also being retroactively applied to existing applications where possible.

Improving a Cloud Deployment Platform

Mon, 10 Feb 2020 00:00:00 GMT

THE PROJECT

One of Improbable’s new acquisitions (let’s call it Company X) had their own single page application (SPA) used to manage and deploy clusters on various different cloud providers. It had been built by a small team, with limited design input and user research. They felt their platform lagged behind those of their competitors and were looking to make improvements.

The Problem
My Role
My Process
The Outcomes

THE PROBLEM

The platform had been built with essentially no user research or testing, by engineers that had a strong understanding of how the core software product worked. This had led to a platform geared towards power users with little emphasis on providing guidance or intuitive workflows.

However, the eventual product vision was to build a new SPA that integrated the Company X platform with Improbable’s existing SPAs. However, the current Company X SPA was expected to remain their main offering for at least another 18 months. This meant that my recommendations would be evaluated on their value add with respect to necessary engineering time. Small changes, with medium to high impact would be prioritised over large structural changes which would be kept in mind for the design of the new integrated SPA.

MY ROLE

As a User Experience Engineer on Improbable’s Web UIs team, I was asked to evaluate the Company X platform for potential UX improvements in both the short and long term. While the primary outcome of this work was to be improvements that would be valuable despite an 18 month lifetime for the platform, a secondary outcome of this work was to be insights for the future design of an integrated platform.

MY PROCESS

UNDERSTAND THE TECH

I started with a crash course (via Coursera and some very helpful teammates) on kubernetes and bare metal deployment to understand how cloud infrastructure worked. It helped me grasp the different concepts and how different elements that fit together. It was my understanding that Company X wanted to have a minimal learning curve for developers already familiar with cloud deploymen†, and so wanted to differ from established conventions as little as possible.

USE THE PLATFORM

Armed with an idea of how I thought Company X’s underlying tech worked, I did a walk through of the Company X platform. I wanted to see if I could make sense of the site map and pick up how things worked just by clicking around. I took note of instances where Company X’s concepts and informtion hierarchy differed from what I was expecting based on my tech research.

ANALYSE COMPETITORS

I was provided with a list of competitor platforms. I created test accounts on each and started to look for patterns and similarities between them. I created a list of shared functionality and compared how each platform UI for it. In particular, I was looking for instances where Company X’s platform did not use an established pattern to do something.

Screenshot of my Competitor Analysis Figma file

THE OUTCOMES

My main output from this project was a slide deck outlining the UX/UI issues I found across the platform categorised into several themes: Navigation, Information Hierarchy, Forms/Inputs, Logs, Styling, Filtering, Layout Inconsistencies, and Contextual Information. The recommendations ranged from UI changes to improve accessibility and usability, areas where additional context or contextual help would be useful, gaps in functionality that users could reasonable expect and structural changes to the platform’s sitemap and structure.

Screenshot of slide deck summary page

As a result, for the meetings with the Company X product manager to discuss the recommendations, I categorised the recommendations by amount of design and engineering time needed: small change, needs minimal design to needs extensive design. This made it easier for the product manager to quickly decide whether he had the engineering capacity to commit to it, and which larger design task he would like our team to further help them on.

IMPACT

At the time of writing, 15% of the my recommendations are Complete, 10% were categorised Won’t Do, 20% were broken down into specific design tasks for my team and 30% are categorised Will Do/ In Progress. 25% were flagged for further discussion and half of the Won’t Do tasks were flagged for consideration during the integrated SPA design.

Screenshot of document categorising recommendations by estimated design work and tracking progress

Understanding User Management

Sun, 09 Feb 2020 00:00:00 GMT

THE PROJECT

In order to provide access to a range of new software products as part of a unified platform, Improbable had built an improved permissions management system. It would provide far more granular control over users and the actions they could perform. A command line tool for assigning and managing permissions had been built. The functionality needed to be integrated into the web interface to allow users to more easily interact with it.

The Problem
My Role
My Process
The Outcomes

THE PROBLEM

The permission management system was very complex and very customisable. We wanted to provide users with a controlled level of flexibility in the UI, without trying to port the full power of the command line tool into a web interface. The goal was to make permissions management accessible to those without a strong technical background and avoid the steep learning curve and complexity that often made systems administration a full time job.

MY ROLE

As a User Experience Engineer on Improbable’s Web UIs team, I helped our lead designer understand how the permission management system worked in the back end, how users were expected to interact with the different concepts, map out various potential user flows. The primary outcome of my work was to be a design proposal for the User Management UI in the new platform.

MY PROCESS

UNDERSTAND THE TECH

I started by reading the system design docs for the permission management system to understand the core concepts and functionality that had been built. I organised meetings with the engineers who built it to understand how they expected users to interact with the concepts. The system was very customisable, and there were a wide range of possible behaviours, not all of which were desirable.

On a high level: within an Organisation, a User’s permissions would be described via their assigned Roles, which represented groups of policies. Policies defined resources and actions that could be taken on those resource i.e. read, write, execute. A user could be assigned multiple roles.

ANALYSE EXISTING SYSTEMS

I looked into how other platforms managed permissions, notably Github, Google Cloud Platform (GCP) and Amazon Web Services (AWS). They each had very different approaches with varying levels of flexibility. At some point, AWS simply provided users with a JSON editor and the technical documentation. In contrast, GCP had a more structured approach with a more clearly defined workflow. However, it still provided significant flexibility and as such had a complex UI, with a steep learning curve.

Amazon's "famed" JSON editor for permissions

GCP's similar Role-based system, with 500+ default roles

IDENTIFYING ASSUMPTIONS

The design of the user management system was shaped heavily by the expectations and assumptions we had for how users would define permissions. We expected people to define Roles relative to their job role. We assumed there would be Roles that could easily be shared between users. We assumed that some default set of Roles would be useful upon starting a project on the platform. These assumptions were built into how the engineering team had build the permissions system, and it was the job of the UI to enforce those expectations without being overbearing. The challenge of this design task was creating this balance.

At this stage, I worked closely with the engineering teams to interrogate these assumptions and test them with the users of the system. It was important we identify false assumptions, or unreasonable expectations and gain a broader understanding of what users would expect from a well-designed permissions system.

MAPPING USER FLOWS

Based on my understanding of how the permissions system worked, I listed:

Actions the user would want to take
- For each action, the steps or information the use would need to provide
Potential pages/screens
- For each screen, information the user would want to see

Using these, I mapped out possible paths between the screens and how they would interconnect depending on what the user wanted to achieve.

Connections between basic screens

Key actions in a basic user flow

At this stage, I compiled my progress into a draft design doc to outline the current state of design insights and sent it to the engineering teams for feedback. It was important I check my understanding of the concepts regularly, in case the abstraction I was designing went off track.

ITERATING ON UI

Once I decided on the basic user flow and screens, I began iterating on different UI styles to display the information. I generated options that used tables, cards, lists, and modals, then shared them with the rest of my team for weekly feedback. I find it useful to categorise my wireframes by actions, to ensure that I cover all the necessary interactions. I also group my ideas by conceptual themes, for example I wanted to test out the idea of making the UI role-centric vs user-centric, i.e. focusing on different elements in the UI. Within these categories, I would iterate on UI styles and layouts.

Laying out my ideas in Figma

THE OUTCOMES

This task was only one section of a larger design task to design Improbable’s new admin platform. Other areas of exploration included Organisation Management, Navigation, Data Visualisation.

This exploration resulted in a interactive prototype of how the User Management pages of the admin platform would look and interact with each other. It also integrated with the Navigation work to lay out how the user would navigate to the user management functionality and its place within the platform’s sitemap.

I also generated a design doc, outlining the stages of design, important design decisions that were made and their justifications. This was annotated with feedback from the engineering teams with clarifying comments about how the permissions system worked in the back end. This would be stored for future reference, as the project wouldn’t reach development for a few more months, and the design would be questioned once more at that stage. It was important I tracked decisions that had been signed off and had answers to any design-related in order to streamline the process.

Improbable Worlds Ltd.

Tue, 10 Dec 2019 00:00:00 GMT

MY ROLE

I currently work as a User Experience Engineer on the Web UIs team at Improbable. As part of my role, I develop single page applications used to develop with Improbable software SpatialOS. The main technology stack is React, Typescript, Redux, Webpack.

Other responsibilities include:

Research, design and build new features
Conduct usability tests on new designs and action feedback in follow up releases.
Build and maintain internal library of reusable components and design frameworks for rapid prototyping
Liaise with API teams to expose new API functionality in the UI.
Collaborate with other teams to provide front end skill expertise to other engineering teams
Mentor non-engineering staff in front end technology skill development

PROJECTS

As these projects are ongoing, I am limited in the details and visuals of these projects that I can provide, but I have provided a basic overview. For detailed write ups of design process, see Case Studies. For higher level overviews of the type of projects I’ve worked on see Page Contents.

CASE STUDIES

Design Improvements for a Cloud Deployment Platform
Understanding User Management

PAGE CONTENTS

Designing the Create Deployment Flow
Scalable Search
Redesigning for Brand Alignment
Redesigning a Web App for Scale

DESIGNING THE CREATE DEPLOYMENT FLOW

I was asked to propose a UI flow for creating a new deployment, a process currently only possible using a command line tool. This required investigation into this CLI process and what information a user was expected to provide when creating a deployment.

With a list of required user inputs, I began to design a UI wizard to guide users through the process. For certain stages, user inputs were more complex than just text and dropdowns. For example, users needed to be able to select from a list of available snapshots and assemblies or upload their own zip files. The launch configuration was a JSON file that also needed to be uploaded, but users expressed strong interest in being able to modify and generate the file through the UI.

As a result, a secondary task of building a JSON file generator UI was cut from the main task. This UI would be integrated into the Config step of the Create a Deployment wizard.

As users fill in basic deployment information, the overview on the right updates. The navigation bar on top shows them the steps they have to take to create a deployment and what stage they are at.

The snapshot step, like assemblies and config requires more complex user inputs

SCALABLE SEARCH

Following the redesign of the Console to support large numbers of deployments (10,000+), a need for the ability to search and filter these deployments quickly became evident.

I worked with the API team to design compatible server side filtering functionality. I researched and designed the UI for basic and advanced search. I also implemented the feature and managed the internal and external release to users.

Some of the main design challenges I faced were centred around different user groups having very different use cases for the feature. For example, some users wanted the search to default to certain filters, while others wanted to be able to save their filters and reapply them later. Balancing all these requirements to build one product required flexibility and compromise.

Mock up for advanced search functionality

REDESIGNING FOR BRAND ALIGNMENT

New brand guidelines were supplied by the marketing team and the team was tasked with updating our web applications to better suit the new style. The challenge was that the guidelines were designed for print and media use rather than UI. The ‘boxy’ style when used for UI threatened to look too old-school, dated rather than modern. Below are a few of the investigations I came up with.

Current design

Example of the new brand's visual look used for inspiration

Redesign Option 1

Redesign Option 2

REDESIGNING A WEB APP FOR SCALE

The aim of this project was to improve load times for the Console, a web app used by SpatialOS developers to manage their cloud deployments.

The current web app had poor loading times for users with large numbers of deployments because the API used did not page data, instead waiting to receive one large segment of data before loading the page.

New APIs had been built, and our team was tasked with reimplementing the web app to hit these APIs, focusing on ensuring that it would still work well when users had 10,000 deployments.

A structural redesign of the sitemap was also needed to reflect changes in how the API stored deployment data. We wanted users to focus on viewing different runs of the same deployment, rather than different deployments in their project. This was due to the realisation that external customers often only had one project, so the multi-project focused view was only useful internally. This change in the information hierarchy we wanted to present was central to our work in redesigning for the Console to work at scale.

Original landing page, showing a user all their projects, then drilling down into the deployments in that project, runs were not visible.

Current design of the new page, with support for 10,000 deployments

Prospective stylistic redesign based on new brand guidelines

3D Experiments

Mon, 09 Dec 2019 00:00:00 GMT

Having just started to experiment with 3D line drawings, I used it as an opportunity to try and learn some 3D modelling skills in Blender.

Working With Fluid Simulations

Original line drawing used as inspiration for the 3D piece

As part of creating the 3D piece, I wanted to make the liquid in the drawing animated. To do this, I used the fluid simulation tool in Blender. I positioned the input and domain objects, and adjusted the viscosity and other settings to mimic a thicker fluid.

The placement of the fluid input objects and viscosity settings required a reasonable amount of trial and error to create the optimal look. The speed of the input flow was also an important factor in creating the drip effect as it controlled the size and quantity of droplets.

Rendered animation of 3D model exported from Blender

Basic Modelling

My first attempts were more static. Based on the drawing shown below, set out creating a 3D scene with various objects and experimented with animations in order to key camera movement.

Rendered animation of 3D model exported from Blender

VR Therapy

Mon, 09 Dec 2019 00:00:00 GMT

My undergraduate individual project was to research, design and build a virtual reality platform for administering Self-Attachment therapy. A full copy of my thesis is available here.

A walk through of the platform

The Motivation
The Goal
The Platform
Designing Interactions

THE MOTIVATION

The premise for this project was formed based on the self-administerable nature of the protocols of self-attachment therapy. The therapy was designed to be practiced by the patient without need for a therapist over an extended period of time to create lasting improvements.

Virtual reality was identified as a viable medium for administering this therapy because it makes significant use of visualisation and imagery techniques. It requires users to imagine interactions with an inner child and attempt to form an affectional bond with them.

As a self-administrable intervention for chronic anxiety and depression, SAT presents a structured method that patients can use to self-manage. By building a cohesive platform that patients can use to guide them through the therapy, a SAT platform could be a powerful contributor to the movement towards making mental health services more accessible. While the protocols designed to help patients conceptualise the inner child are highly structured and have proven effective, the feedback received often highlighted the difficulty of this visualisation. By introducing patients to Self-Attachment Therapy through a virtual inner child, the aim is to help patients more easily transition to practicing the protocols with an imaginary inner child.

THE GOAL

Overcome Barriers to Accessing SAT
The primary reason for considering the use of VR for administering SAT was because it could help users who could not sufficiently imagine their inner child to visualise the inner child and therefore undertake SAT.
Ensure Accessibility
As a platform used to administer a medical intervention, it is important it is accessible to those with special needs and disabilities.
Integrate Speech Recognition and Motion Detection
This platform's development seeks to demonstrate that in VR motion detection and speech recognition are viable alternative methods of collecting user input.

THE PLATFORM

STAGE I

In this VR platform, in addition to introducing patients to self attachment, Stage I also provides onboarding for first time users of VR. For more detail on how the onboarding process was designed see 4.5 Designing the Onboarding Experience.

Therefore, as the primary aim of Stage I is educating the user, both in SAT and in how to use the VR platform, the design and experience of the room, is different from the other stages. Stage I centers around a screen wherein users can click through a set of slides (see B.1 Stage I) with instructions detailing how to navigate the VR platform, i.e. using controllers and speech control, as well as a brief introduction to Self-Attachment Therapy and the role of the VR Inner Child.

The Stage I Room: providing an introduction to to SAT in VR and the inner child

STAGE II

The menu in Stage II consists of three separate activities that the patient can choose between:

Happy Activity
Through a series of questions, the patient is invited to recall and reflect on a happy memory from their childhood, focusing on how the behaviour of their primary caregivers affected the experience. This activity does not involve any direct interaction with the VR inner child; the patient simply reflects on a series of questions presented as part of the instruction set.
Sad Activity
Through a series of questions, The patient is invited to recall and reflect on a sad memory from their childhood, focusing on how the behaviours of their primary caregivers affected the experience. This activity does not involve any direct interaction with the VR inner child.
Compassion Activity
The patient is presented with a distressed child and asked to offer it verbal and physical compassion as they would have wanted. In this activity, the patient is asked to 'cuddle' the VR inner child to offer it physical compassion.

Stage II Activity Menu allowing users to choose between activities

STAGE III

In these activities, there are no direct interactions with the VR inner child. The patient either reflects on a series of questions presented as part of the instruction set, or performs an action ‘with’ the inner child, who is given a fixed animated behaviour for each activity. The menu in Stage III consists of four activities the patient can choose between:

Singing Activity
The patient is invited to imagine they are forming a deep affectionate bond with the VR inner child while singing their happy song and moving their body to the music. A pre-selected karaoke music video is shown on the screen in the VR room.
Dancing Activity
The patient is invited to imagine they are engaging in a loving dialogue with the inner child and bonding while dancing along with the inner child. A pre-selected dance video is shown on the screen, giving the patient different dance moves to follow.
Self-Massage Activity
The patient is shown a video tutorial on how to perform self-massage. They are invited to imagine they are physically interacting with the inner child while performing the massage.
Pledging of Love Activity
Through a series of questions, the patient is invited to reflect on optimal parenting behaviours and vocally pledge to love and support the inner child unconditionally.

Stage III Activity Menu allowing users to choose between activities. The screen displays the self-massage, singing and dancing videos for each protocol.

STAGE IV

In Stage IV, the patient can choose from a series of subprotocols A, B, C, D, E, F. Protocols A - D involve either some form of physical interaction with the child, and/or a transition to a different, specially designed protocol room. Protocols E and F are stationary reflection protocols that take place in the main Stage IV menu room.

Stage IV menu allowing users to choose between subprotocols.

Type A - Process Past Trauma
In a blackout environment, the patient is invited to recall a traumatic past event, focusing on how they would have liked their primary caregivers to have supported them. The patient is then presented with a distressed child and asked to offer verbal and physical compassion as they would have liked. The patient is asked to 'cuddle' the VR inner child to offer it physical compassion. Upon successfully consoling the child, the initially dark and bare room then opens up to a better lit, furnished room.
Type B - Process Current Trauma
The patient is invited to reflect on any current negative emotions and project them onto the inner child. The patient is then presented with a distressed child and asked to offer verbal and physical compassion in their role as the adult self. The patient is asked to 'cuddle' the VR inner child to offer it physical compassion. Upon successfully consoling the child, the initially dark and bare room then opens up to a better lit, furnished room. The experience is identical to Type A, except with different instructions.

Black out environment with instruction text for Protocol Type A.

Dimly lit room where patient is asked to console a distressed child.

Brightly lit, furnished room emerges from behind a raised wall after the patient offers verbal and physical compassion to the inner child.

Type C - Create Zest for Life
The patient is presented with a mirror in which their reflection has the image of the inner child. They are asked to sing and dance in the body of the inner child; an illusion created by the VR mirror through motion detection. They are also asked to try and integrate singing and dancing with the child into their daily life, so as to maintain a constant relationship with the child and use it to tackle negative emotions, habits and addictions.

The patient is presented a mirror where their reflection has the image of the inner child. The child mirrors changes in position, rotation and basic actions like dancing and a raised hand.

Type D - Gestalt Therapy
The patient is presented with a black and white image of the gestalt vase on a screen behind the VR inner child. They are able to to invert the image colours, toggling between focusing on seeing a vase and seeing two faces. This represents positive and negative interpretations, enhanced by a corresponding toggling of the inner child's expression between happy and sad. The patient is asked to focus on transforming negative emotions into positives by recalling the powerful pattern of love built with the inner child. This activity does not involve any direct interaction with the VR inner child. The patient simply reflects on a series of questions presented as part of the instruction set.

According Gestalt Colour Therapy, viewers are drawn to focus on darker elements of the image. Hence this colouring draws attention to the two faces interpretation of the image. This is associated with positive emotion because it can interpreted as the faces of the adult self inner child, representing their bond.

Gestalt Colour Therapy suggest that viewers attentions will be drawn to the darker coloured shape of the vase. This is associated with negative emotion because it represents an endless accumulation of dark thoughts.

Type E - Outward Socialisation
The patient is invited to try and habituate the protocols into their everyday life and extend the compassion developed for the inner child toward others. They are asked to take on the role of the good parent, continuing to display affection as well as discouraging the inner child from acting on negative emotions. This activity does not involve any direct interaction with the VR inner child. The patient simply reflects on a series of questions presented as part of the instruction set.
Type F - Optimise Internal Working Model
Through a series of questions, the patient is invited to reflect on how their negative schemes of thoughts and feelings stemmed from the behaviour of the primary caregivers when they were a child. They are then asked to begin practicing a modified Type B protocol, focusing on identifying the roots of any negative emotions in their family background and childhood relationships. This aims to help them understand their internal working model. This protocol relies on the long term nature of Self-Attachment Therapy, asking the patient to gradually emerge from the view of themselves as a prisoner to their early relationships and create a more optimal internal working model for interpreting and managing relationships. This activity does not involve any direct interaction with the VR inner child. The patient simply reflects on a series of questions presented as part of the instruction set.

DESIGNING INTERACTIONS

An overview of the physical interactions of cuddling and mirroring in the platform

CUDDLING THE CHILD

In the third and final iteration of this experience, joystick navigation had been removed from the platform in favour of a more stationary experience. This was because as the protocols were designed, it became clear that the ability to move freely around the VR environment beyond a few steps was not particularly useful except for the cuddling experience where users had to use it to fine-tune their position. In addition, early user testing raised concerns about motion sickness and the ease ofuse of the joystick controls. This indicated it could become a further barrier to access for less technologically acquainted users.

Therefore, in the final version, the assumption was that the user would be relatively stationary meant the child no longer followed the user around constantly. Instead, it stays in a fixed position until the protocol requires a cuddle. It then walks directly forward until it is close enough to the user to receive a cuddle. The user may still have to make slight adjustments to get closer or lower, but these are very small and quite intuitive. Once the user’s hands are detected to have ‘cuddled’ the child, the child turns and walks back to its original position. In this way, the bulk of the set up for cuddling is performed by the VR platform by guiding the child towards the user.

1) The child starts in a fixed position

2) The child walks towards the user

3) The user reaches out with both hands to give the child a cuddle

4) After a successful cuddle, the child walks back to its starting point

MIRRORING THE CHILD

The mirroring component of Stage IV Protocol Type C presented a unique design challenge. The non-VR protocol asked users to perform the protocol standing in front of a mirror. Therefore, it followed that the VR platform should provide a mirror in the VR environment. The aim of the mirror was to help users imagine that their image in the mirror was that of their inner child. In VR, it is possible to create the illusion that the user’s body is physically embodied within the child’s body. Therefore, when looking in a mirror they actually see the child’s reflection as though it is their own.

However, it became evident that the quality of the illusion’s realism was dependent not on the mirror, but the ability for the child model to copy the user’s movements in real time. This was limited by the number of animations available for the child model and the level of tracking the Oculus provided. For example, it would be difficult to animate the child to copy the user’s walking motion as there are no sensors on the user’s feet or legs.

Therefore, the design of the mirroring experience was limited by what was viable in the time available given it was only a small section of the platform. It represents a proof of concept towards what could be possible if more time was dedicated to build and calibrate real time avatar mirroring into the child model.

The child model mirrors user position and rotation without animation. The model can also detect and mimic the motion of raising a hand above the head. The protocol also calls for users to dance and sing to their happy song in front of the mirror. To facilitate this, a dancing motion was defined based on the child model’s provided dancing animation. Users move their arms from side to side and once this motion is detected, the child mirrors this motion until the user stops moving. This is intended to provide the experience of dancing while embodied within the child body. The user is introduced to what activities can be performed with the child in the instruction set for the protocol. The instructions incorporate a guided tutorial for how to engage with the motion detection capabilities available before allowing users to experiment freely.

p5.js

Sun, 08 Dec 2019 00:00:00 GMT

Inspired by the creative coding community on Instagram (@zach.lieberman, @kiyoshinakauchi), I wanted to learn to use a creative coding framework like openFrameworks. I found openFrameworks very difficult to set up on my machine, and further investigation led me to sketch.js and p5.js. These were much easier to use with the added bonus of being written in javascript, a language I was familiar with.

The community on codepen.io was very helpful for finding inspiration, and looking at other people’s work and code really helped me understand what was possible and how to get started.

See the Pen Sparks by Amanda Koh (@amandakys) on CodePen.

See the Pen Magnetic by Amanda Koh (@amandakys) on CodePen.

Emblem Builder

Sat, 07 Dec 2019 00:00:00 GMT

MY ROLE

Disclaimer: Details have been omitted to comply with my non-disclosure agreement.

This was a project I worked on as a UI Artist at a games studio that was maintaining a live free to play mobile title. I was given a brief for an emblem builder that would allow players to create a custom emblem for their team. I was responsible for designing the structure of the emblem creation experience as well as prototyping the interface. I researched existing solutions, designed screens and put together an interactive prototype in Adobe XD and Marvel (shown below). I created high fidelity mock ups of the builder in the visual style of the game. (Unfortunately, I can not share these visuals). I also investigated implementation strategies in the Unity game engine using NGUI.

The Problem
The Research
Designing The Structure
The Prototypes

THE PROBLEM

In the existing system, players were able to choose an emblem from a finite set of pre-designed choices in a variety of colours. This restriction of choice conflicted with the long term goal of improving player engagement by providing opportunities for individual expression (a theme also explored in my work with Emojis). The idea of an emblem builder was not new to console/PC games. However, on a mobile interface, the restrictions on screen space translated into a lack of customisability due to difficulties integrating complex controls.

THE RESEARCH

In my preliminary research, I investigated existing emblem builder solutions in console/PC games. In particular, I wanted to understand how they broke down the emblem building process into smaller steps. Generally, I found there were two types of approaches.

FOREGROUND/BACKGROUND APPROACH

The builder provides shape options for use in the foreground or background. Foreground shapes are more complex and detailed while background shapes are bolder solid shapes. The approach is resonant of the ‘engraved crest’ where a crest shape and engraved pattern was chosen. The two shapes could then be coloured individually.

The emblem builder in Halo and Guild Wars is a good example of this.

Halo Emblem Generator

Players choose a foreground and background shape then colour each one separately from a different screen.

Guild Wars Emblem Generator

Supports two colours on foreground shapes allowing players to choose a primary and secondary colour, bringing greater colour variety.

LAYERED SHAPES APPROACH

The builder allows players to layer individually coloured shapes on top of each other. Some would also allow shapes to be individually resized and positioned rather than automatically centred. This approach is reminiscent of photoshop and lent itself to increased creativity as even with simple shapes, players could create an infinite number of designs.

The emblem builder in Battlefield 4 used this approach.

Battlefield 4 Emblem Generator

Allows users to layer shapes on top of each other and colour them individually. The shapes have a varying levels of complexity but can be composed together to make a huge variety of designs.

DESIGNING THE STRUCTURE

Before starting to prototype the interface, I had to pitch the emblem creation process that I wanted to implement. My proposal broadly followed the ‘Layered Shapes Approach’, but I made a few key modifications and additions to suit our game and the mobile interface.

Touch gestures for scaling and positioning shapes.
Shapes would be offered in bundles that could be unlocked or purchased (to provide long-term monetisation and extension potential).
Colour control would be offered through a fixed set of 12 swatches and users would adjust lightness darkness to create variety.
Text could be used on emblems, but text content could not be customised (to avoid inappropriate content). Players could only display their team name, but could choose from a variety of render styles which could be also be offered in bundles.

THE SOLUTION

Interactive prototype of final emblem builder design

One of the key frictions in previous iterations was the display of the layers. I couldn’t decide whether the top most layer should be shown on the right or left, and similarly which side the “Add New Layer” should be on. Interviewing several of my team for input led to a huge variety of views on what set up would ‘make sense’. I realised that if what was right wasn’t clear, perhaps the whole approach was fundamentally counter-intuitive.

This version was designed with a vertical layer stack in mind. This way there would be no dispute as to which was the top layer. It is also the version which I feel truly shed the influence of the console/PC versions I had initially used as inspiration. I also maximised the canvas area in line with the decision in Version 3 to fully commit to touch gestures as the main method of interacting with shapes. This was instead of the ‘full screen mode’ I had previously incorporated to give users a screen with a larger canvas.

The reduced area available for the menu due to the larger canvas increased my reliance on context based menus. With just a one column menu to work with, I had to break down my workflow into even smaller steps. The main challenge with this was how to go backwards. In an ideal situation, users would progress linearly forwards, but in the use case where users needed to return to a previous menu, I decided to have the ‘back’ button go back one step at a time. While this could be tedious for big changes, for the general use case it was largely sufficient in a context based menu system. Instead of having a dedicated back button, the title of the current menu served to return users to the previous menu. This was in line with an existing convention in the game and saved screen space.

Note: The back behaviour was hard to incorporate into a manual prototype due to the need build an excessive number of screens to accommodate all the changes to the canvas. To see it in action I would recommend trying it in the first few screens of the prototype above.

THE PROTOTYPES

My design for the interface went through three iterations before reaching a layout and workflow that was I was happy with. The main challenge was making the design simple enough to be used on a small mobile screen while still providing access to a certain level of control. Each iteration was evaluated by other members of the UX/UI team and I continued to iterate until I stopped getting “make it simpler” as feedback.

VERSION 1

Also known as the ‘Power User Version’, my first version encompassed all the functionality I could possibly want in the emblem builder in a single screen. The use of the accordion collapsing menu style, drop down menus and toggled menus were my attempt build for a small screen size while maximising element size and still providing a variety of options.

Importantly, since I wanted to use touch gestures to manipulate shape size and position I endeavoured to make the canvas size as large as possible on the screen. This limited the remaining space available for the menu.

The menu represented the three stage process I envisioned for the emblem building process.

Choose a background shape and texture
Add additional layers of shapes and choose their colour
Choose a render style for displaying your team name

Drop down menus were used to facilitate the bundle system where shapes came in bundles which could be unlocked or purchased. The toggle menu was used to switch between the Colour/Texture menu and the Transform menu which provided an alternative to touch control for the scale and position of shapes.

The use of a slider in the colour and transform menus were used to provide a more touch based interface instead of requiring text input. For colour the slider adjusted the lightness/darkness of the chosen colour swatch. For transform, the slider would adjust numerical values depending on the chosen transform i.e. for Horizontal transform, the slider would move the shape from left to right.

Animated slideshow of the screens designed for Version 1. Exported from Adobe XD.

VERSION 2

In this version, I focused on making the menu interface as simple as possible given the same amount of screen space. I removed the distinction between Background and Shapes, reducing the types of layers that could be added to just Shapes and Text.

Moving away from the accordion menu style to a more context based menu, users are asked to specify which type of object they’d like to add before being shown the relevant menu. I made use of the previously unused screen space on the left side by moving the transform menu underneath the canvas. The new system provided a more guided workflow where users were presented with a limited amount of choice at each stage and once choosing a direction, changing it was more complex than in Version 1.

For example, in this version users the menu options refer only to one layer at a time, and the layer is chosen at the beginning of the workflow. The menus then displayed refer only to the shape on that layer. To change layer the user must navigate back to the start menu. I essentially designed a core loop of interaction to be repeated until the user completes their design.

Animated slideshow of the screens designed for Version 2. Exported from Adobe XD.

VERSION 3

While Version 2 represented a significant simplification of Version 1, the general feedback was that it still felt clunky and crowded. It was fine for a tablet sized device, but for mobile sized devices would still be too fiddly. To simplify the interface further I stripped back the functionality I wanted to provide.

I removed the transform menu and thus the ability to control scale and position via on screen controls. Users would just have to use touch gestures.
I removed the shape preview from the menu. Previously after selecting a shape, a larger preview would be shown in the menu and colour applied to this preview before being added to the canvas. However, I realised this was extraneous as the shape could just be immediately previewed on the canvas.

A key change in Version 3 was the redesign of the layer display system. Previously, the different layers could only be viewed from the initial menu and not in the later context based menus. However, the layers themselves were not directly related to the provided contexts i.e. whether the user was adding a shape or text. Therefore, I endeavoured to make it possible to view all the layers in the emblem at all times. By putting the layers on screen at all times, it allowed users to easily switch between which shape/text layer they were modifying and make quick changes to a shapes they had added before.

Animated slideshow of the screens designed for Version 3. Exported from Adobe XD.

InTune

Fri, 06 Dec 2019 00:00:00 GMT

MY ROLE

I was part of a team of 4 developers who worked on this web application. As a code heavy project, I took on the role of designer both for my team’s benefit and for personal development. In this capacity I worked on interface and user workflow design.

As a programmer, I focused on front end development and integration. My main back end contribution was implementing multi-user functionality outside of concurrent editing. For this, I implemented notifications, comments and chat systems.

The Problem
Our Solution
Designing User Flow
Key Design Decisions
The Prototype Feedback
The Future

THE PROBLEM

POOR FILE MANAGEMENT

Existing music notation software lacks version control, and over the course of a collaboration, many copies of the same file build up. It is not uncommon to a project folder with file names like “Composition – V1”, “Composition – V2” and so on. It quickly becomes difficult to know whether they are working on the most up to date version. In addition, merging changes between composers who initially started on the same file is also convoluted.

FRAGMENTED COMMUNICATION

Musicians often email each other different versions of the ‘current’ music notation file to keep each other up to date. With large file sizes and proprietary file types, this process is fraught with unnecessary complexities. In addition to email, collaborating musicians often communicate through some kind of team management software like Slack, or simple through a social messenger like WhatsApp, Skype or Facebook. It is not uncommon to see a mixture of images, audio recordings and videos being sent to discuss the music notation. It can become hard to keep track of these messages, especially for longer collaborations.

OUR SOLUTION

CONCURRENT EDITING

To tackle the problem of poor version control and a complicated workflow for remote collaboration, we envisioned a concurrent editing system for music notation. Our goal was Google Docs, but for sheet music. It would be possible for multiple composers to work collaboratively on a single shared copy of the composition. When editing concurrently, they would see each others changes live.

In addition, a simpler version control system similar to that which we (as programmers) were familiar with, would allow composers to browse through a linear history of saved versions. In conjunction, these features would eliminate the need for composers to send each other updated copies of music notation files.

BUILT IN COMMUNICATION CHANNELS

To tackle the problem of fragmented communication and ensure that our web application provided the most all-encompassing composition experience, we designed built in communication systems that complemented the composition workflow.

1. Comment on each bar of the composition

To allow for detailed discussion about specific areas of the composition, each bar has a separate comments section to allow for annotations, suggestions and discussion.
This allows composers to keep track of the changes they made to this bar and the conversations they had that led to them.

2. Separate chats for each composition

For more general discussions i.e. about the tone of the piece, time signatures or arranging meetings, each composition has a chat that allows all composers involved to communicate.

With these features, composers should have no need to leave the app during the composition process. In addition, all records and notes about their compositions would be conveniently stored in one place.

DESIGNING USER FLOW

When designing the user journey through the application, it was important I had a strong vision about where our application belonged in the world of music notation software. Our focus was collaboration. We were not looking to compete with existing music notation software available on the market which provided incredibly powerful and comprehensive notation scribing capabilities.

Instead, we wanted to provide a platform for collaboration, where notation capabilities were functional but not central to the whole experience. With this in mind, I set out to design workflows and screens that emphasised the applications collaborative capabilities.

THE CORE LOOP

In line with our focus on collaboration, we wanted our platform to be a community of composers. Having user profiles allowed us to achieve this and was the intuitive strategy for giving the app a long term presence in a composers workflow. It should be their go to application to view all their composition work or start a new composition.

A straightforward ‘goal-based’ homepage makes it easy for composers to get started on their projects.

THE CENTRAL EXPERIENCE

The majority of the application’s core functionality was built around the central function of editing a composition. It presented a challenge in terms of screen design as it was important that each feature got adequate but suitable screen real estate and featuring. Similarly, designing how they all interacted with each other to create a intuitive composition workflow required significant trial and error. This is discussed further in Key Design Decisions.

An outline of the possible actions that can be taken from an Edit Composition Page. The majority of features that we designed, like version control and chat start from a composition.

KEY DESIGN DECISIONS

TEXT INPUT VS MOUSE INPUT FOR NOTATION

Our investigation into which method of notation input our application should use started as a discussion about preference. However, it soon grew to a larger debate about usability, flexibility, our target audience and the reasons for which we intended our app to be used.

Existing music notation software is largely text-based, incredibly thorough and very powerful. For the purpose of scribing music notation, there is little that the key players are lacking, especially as they have been leaders in the field for years. While it was tempting for us to try and introduce a ‘beginner friendly’ mouse or drag and drop input method, I soon realised that to develop a system with equivalent levels of customisability and thoroughness, mouse input didn’t really have a learning curve that was any less steep. Notation that took two keystrokes to achieve would translate into 10 mouse clicks through numerous menus with a huge number of options. This was not only less efficient but despite having an ostensibly simpler interface would represent a completely new interface for users familiar with existing music notation standards. Thus, a large section of our target audience would have to learn a new notation system just to use our application.

This led us to really narrow down who our target audience was. In particular, whether they would have music notation experience and whether text-input would represent a significant barrier to entry for them. The goal of our app was to help musicians compose sheet music together, not help aspiring musicians learn sheet music, or remove the need to understand notation altogether like some sound-input applications. With this in mind, we came to the conclusion that our target audience would not be hindered by a text-input system, and those who were would not be converted by a mouse input system as the main barrier to entry was knowledge of music notation itself.

Finally, our project roadmap beyond this initial prototype included developing a mobile version. Given the focus on collaboration and the ability to compose in groups remotely, the intuitive next step was the ability to compose ‘anywhere’ using a mobile device. With this in mind, text-input was the clear choice compared to trying to use a fiddly touch input system on a mobile phone. It didn’t make sense to develop a whole new input system for mobile, especially if it involved a significant learning curve (as discussed before). Thus, text-input was the most scalable solution.

In the future, it may become viable to introduce a mouse input option to widen our user base, and help more musicians access to notation software, but for our initial build we decided on text-input.

Users edit the composition on a bar by bar basis to keep the text notation manageable. The summarised notation guide provides the keyboard shortcuts for common notation for easy reference. It can be expanded into the full notation guide. The Edit window can be hidden/show as needed to maximise viewing of the composition itself.

THE EDITING WORKFLOW

Throughout the whole design process, I remained very aware of existing notation solutions and strove to remain distinct and true to our initial visions in my design. It was important that we didn’t become “just another online notation product”, but distinguished ourselves as a collaborative platform.

I wanted the collaborative flow our app to complement the editing workflow so that users could switch between communicating with team members and editing notation smoothly and intuitively. To achieve this, I devised different communication channels and aligned them with different parts of the editing workflow. Comments would be aligned with the Bar by Bar editing structure, so users could comment on each bar individually. This would provide a structure for organising annotations on the music as well as facilitate detailed discussion about the music. The chat would be aligned with each composition, providing a medium to discuss the piece more holistically as well as general team administration. Finally, notifications would tie these channels together by providing user with a summary of all activity in all their compositions.

Users are notified when any composition they are involved in is, edited, commented on or receives new chat messages.
Users can share their composition with others to start a collaborative composition
Unread comments on a bar are highlighted on the composition
Users can chat on a per composition basis, to keep their conversations organised.

Upon selecting a bar, users can view existing comments or add a comment. The Edit and Comments pop up can be quickly hidden when not needed to maximise the viewing area of the composition.

In addition, as part of the concurrent editing functionality, users can see if another user has selected a bar. It is not possible to edit a bar currently selected by another user. This is a restriction designed to prevent clashing changes.

Each composition has its own chat, allowing users to keep their discussions organised. To help incorporate existing chat behaviour we observed from collaborating composers, we added a few key features to our chat:

Reference bars from within the chat. @Bar21 will bring up that bar in the chat window
Input notation text into the chat. Users can compose a bar send it as a message. The bar can then be quickly added to the main composition.
Send photos and audio snippets

TECHNICAL OVERVIEW

For this project, we made the decision to use the Django framework to develop this prototype because it had strong front end to back end integration and its grounding in the model view controller implementation theory was familiar to us. In addition, with a very limited time frame to deliver a working proof of concept, we wanted to reduce our learning curve by developing in Python, a language we were already familiar with.

Alternatives we strongly considered were Node.js and Ruby on Rails. We had no experience with Ruby and Node.js was not as thorough as Django in providing structured back end interaction. In particular, we anticipated the front end of displaying and editing music notation to be the main challenge of our project and wanted to minimise complications in the back end and database management, for which Django’s built in Object Relational Mapping was ideal.

For the front-end, we used the Bootstrap library to streamline HTML and CSS development. As seen in the screenshots of our initial product, we prioritised functionality and honouring basic layout design over visual aesthetics through extensive CSS customisation.

System Architecture Diagram
A break down of our code base structure. Our system design was heavily influenced by the Model-View-Controller architectural style. A key element was the use of Django Channels to build collaborative functionalities i.e. comments, chat, notification and live changes while editing.

RENDERING MUSIC NOTATION

After some research, we chose to use the VexFlow API and its VexTab language as the basis for our notation rendering capabilities. We built an intermediate language between its text input structure and the one we wanted our app to use. We then developed a system to serialise its data so it could easily stored and retrieved from our database. Once this was working, we focused on integrating Django Channels so that changes to the composition would be displayed live to facilitate better concurrent editing.

HANDLING WEBSOCKETS

When researching how to implement realtime functionality into our application (especially for a live chat), we were initially drawn to socket.io as a framework to help us build with the WebSocket protocol. However we were disappointed to discover that while Django integration did exist, it wasn’t the most reliable or well-documented. We eventually discovered Django Channels which provided similar functionality. From here, building live chat and comments was straightforward with a thorough perusal of the documentation and examples. However, integrating it with our notation rendering system was a challenge that took over a week.

THE PROTOTYPE FEEDBACK

After 4 weeks of work, we had a functional build ready as a proof of concept and a basis for user testing to guide further development.

While I was implementing the front end, it was useful to have the wireframes as a guide. Due to our short timeframe for the initial implementation, I received some pushback from my team about designing with wire-frames. However, taking the time to make wireframes ultimately saved me time, as it was less time consuming than iteratively implementing design elements in code. It gave me more flexibility to be responsive to feedback.

From a design point of view, the visual implementation of the build is largely focused on functionality rather than aesthetics and the use of Bootstrap is evident. However, during our user testing we received feedback that while it looked a little boring, it was clear and easy to use. The overwhelming feedback was that the basis of our user experience was well designed, but we could improve by developing the aesthetic of our user interface.

EDIT

The Notation Guide was well received, and having a summarised version easily accessible noticeably eased the learning curve. On average, users took 10 minutes longer to write their first bar when the summarised guide was not available. In addition, the number of times they referred to the full notation guide decreased faster when the summarised guide was available. Without the summary the first bar took an average of 12 views of the full guide, while the 5th bar took 5 views ( 58% decrease over 5 bars). With the summary, the first bar took 10 views but the 5th bar only 1 views (90% decrease over 5 bars).

COMMENT

Users were quick to understand the Bar by Bar comment organisation system, but were not as comfortable incorporating it into their workflow. They felt the system was too restrictive and preferred to use the chat for discussion so they didn’t have to worry about “putting the comment on the right bar”.

The ability to see which bar had a new comment was well received, but led several users to ask instead for a highlight if the bar had been changed instead. It was felt that highlighting a “New Change” would be more useful than “New Comment”. Users wanted to easily see where and what recent changes had been made by the other composers.

CHAT

The Chat feature was a favourite of many users. It integrated quickly into their workflow and they were very comfortable using the built in extensions that incorporated notation editing. However, a common frustration was that the notation guide was not easily accessible from the chat. This lead most people to photograph hand written notation instead and input it later in Edit mode. The @Bar__ functionality was very well received and was sent more often than images and audio. Users noted it would be useful to be able to show a range of bars too i.e. @Bar2-4.

SHARING + VERSIONS

Users can Share the composition with others that they have connected with on the platform. This gives them the ability to view and edit the composition concurrently. It provides a platform better remote teamwork and file management.

Users can also save Versions of their work at specific intervals with a description about the key changes. This is in addition to a regular save that does not add a new version. From this we save the emergent behaviour of Versions being used to bookmark a users contribution to the contribution. For example, after working on the composition for a few hours, users would save a version with the description “Name, added 10 bars in bridge”. From this, we intend to add a feature to make it easier to attribute each change to a user.

THE FUTURE

Going forwards, we are looking at implementing new features that have emerged as useful through user testing i.e tracking changes and attributing them to composers. We are also modifying existing features to better suit user needs i.e. Comments by Line. A priority for us is building a mobile version, so that we can better fulfil our vision of a collaborative platform that facilitates composition on-the-go. In addition, we are also in the investigative stages of implementing audio playback functionality. We intend for this to further extend the scope of our end to end composition service.

Portfolio Website

Thu, 05 Dec 2019 00:00:00 GMT

The Motivation
Choosing the Right Tools
The Setup
The Design
Building the Slider

The Motivation

When I was looking for graduate jobs in 2017, as a computer science student looking to break into UX design, an online portfolio was crucial. That summer, I built my first Wordpress site and wrote my first case studies for the projects I’d done over the last few years. At the time, I would have loved to have built a website from scratch, but with little javascript experience I chose Wordpress to economise on development time and focus on writing the content.

Fast forward to 2019. After working as a UX Engineer for over a year, applying to graduate school once more required an online portfolio. This time, I leapt at the opportunity to put my newfound javascript skills to good use.

Choosing the Right Tools

The most straightforward way I knew to start building a website was to write HTML, CSS and Javascript files, buy a hosting package and domain name, then host the files on that server and point the domain name at it. Even using Wordpress, my first website had required navigating the complex world of cPanel and Namecheap.com’s awful interface to make my site go live.

However, since 2017, static site generators had come to my attention. They were more complicated to use than a Content Management System (CMS) like Wordpress or Squarespace, but provided a level of customisation that I liked. For the purpose of a portfolio website, a static site was more than sufficient as there was unlikely to be heavy user database interaction.

For hosting, rather than pay $40 for a hosting package off Namecheap.com, there were now options like Github Pages, Heroku and Netlify that offered free packages. These were especially convenient as I wanted to put my code up on Github, so anything that could just pull the files off Github would be ideal.

After this initial discovery stage, I had two key decisions to make:

Which static site generator to use
Which hosting service to use

For static site generators, I investigated Hugo, Gatsby, Jekyll and Drupal. Ultimately, the deciding factor my preference for using React, which I already familiar with from work. Gatsby was the only framework written in React and it had easy integrations with a wide range of hosting optins, including Netlify and Heroku. Hugo was a close contender, as it had similar integrations and was written in Go, which I was interested in learning. However, I decided to pick my battles and focus on the learning curve of building the website rather than tackling a new language.

For hosting, Heroku was less suited to hosting static website and had a far less generous free tier. Gatsby had Netlify integration built-in and deploying a site was a simple matter of linking Netlify to my Gatsby code on Github and few more clicks. The Gatsby Netlify pairing was also well documented by both services and the internet in general.

The Setup

It took just over a day of work to host the default Gatsby template on Netlify, but there were some teething problems connecting my own domain name as it needed to be moved over from Namecheap’s server. It was interesting to watch the new nameservers being propogated through the internet - a process that took a few hours. Once this was done, I had a live site deployed that would auto-build when changes to master branch of the linked Github repository were detected.

GraphQL

One of the main features of Gatsby was its use of GraphQL. It was a query language, like SQL. It was how data, like the images on a page, were queried and served to the components. I had never used it before, but the examples in the template were a useful start.

It was an incredibly powerful way to programmatically generate pages. All the pages on the site are written as Markdown files which are then served to shared page template. This ensured consistency and meant I didn’t have to write a whole new React component for each project.

It also allowed me to filter the Markdown pages for files marked as a “Case Study” and display them on a separate Case Studies page quickly and without any code duplication.

Of course, this convenience did come at the cost of customisation and I often found myself working around the template to make a simple feature that was only needed on a single page. Overall however, I felt it was a valid compromise.

The Design

A portfolio website is all about the image you want to project. It represents a showcase of your work and your personal style, available for all to see. As I was building this website, it was very difficult not to be incredibly self-conscious and question every design decision I made.

I knew I wanted a minimalist, image-centric design with clean lines and bold colours. As a visual designer, I wanted the pictures of my work to catch the eye, but as a UX designer I knew I had to put in good case studies to back up the pretty pictures.

The visual design of the website is purely personal preference. I experimented with colour themes and fonts until I found a combination I liked. It was difficult to resist the urge to add more colours and use exotic fonts, but with the guidance the designer at work, I was able to resist the common pitfalls of amateur web design. The software engineer in me pushed very hard for a dark theme, but I ultimately settled on a monochrome light style because it felt cleaner and more optimistic.

Home Page and Case Studies Page

The main lesson I learned from my previous portfolio website was to make it as easy as possible for people to find what they wanted, regardless of what they were looking for. My potential viewership included recruiters, potential employers and graduate school admissions officers all looking to evaluate me based on different criteria.

The aim of the Home page was to display all my projects in a way that would help people gain a sense of my skills and interests, from web development and UX design to digital art and photography. I then made a separate Case Studies page to make it easier for people to filter out my personal art projects and focus more on the detailed write ups of projects.

Content Pages

Case studies were often quite long, in particular mine often included design and technical implementation details. To help viewers evaluate their interest in the case study, I started with overview sections like My Role and The Motivation before delving into more detail. Even with this, I felt it would be useful for users to be able to click through to relevant sections, rather than skim and scroll through to find the parts they were interested in.

To achieve this, I used page anchors and provided a Contents section at a point in the case study where I felt it would be useful to provide users insight into what content followed. I deliberately chose not to put the Contents section at the top of every page because I felt it would discourage viewers from reading the contextual information provided about each project. Instead, after initial descriptions of the project, users are able to use the Contents section to navigate to sections that provide detail on areas of the project they might be more interested in i.e. design process or implementation details.

Building the Slider

My original website had a Before After Slider as its landing page and I remember spending hours on the artwork for it. I wanted to port this feature to my new site, but this time I couldn’t use a Wordpress plugin.

I built my own Before After Slider from scratch in React (see it here), querying the images using GraphQL, then manually positioning the images with CSS. The animation of the image widths was done using the React Motion library, an easy way to add customisable spring animations to React components.

Promo

Sat, 04 May 2019 00:00:00 GMT

MY ROLE

I was brought on as designer after the idea won a university app pitch competition. The team consisted of the founder and two developers. I was responsible for the visual and user interface design of the app as it moved from concept to first functional build and into later iterations. My responsibilities included, structural and experience design, wire framing and generating high fidelity mock ups.

The Aim
The Problem
The Personas
Designing User Flow

THE AIM

To provide a simple, streamlined experience for:

Social media influencers looking to monetise through brand affiliations
Products and brands looking to use social media exposure for marketing

THE PROBLEM

Fragmented communication channels
- Almost all social media has a personal messaging system. For influencers with large profiles spanning several platforms, offers to promote a product could be sent to any of them.
One-sided outreach
- At the moment, marketing teams tend to make first contact with influencers they are interested in collaborating with.
- Opportunities to contact marketing teams are limited and are often very noisy channels.
Lack of quantitative metrics
- Marketing teams struggled to access and analyse data to quantify the return of influencer based marketing.

THE PERSONAS

Ashley

Ashley is a fashion blogger with 10,000 followers. She’s been contacted by companies in the past asking if she’d be interested in being paid to wear their clothes in her posts. With the number of requests increasing and coming from a variety of sources, she wants to be able to manage them efficiently, cultivate more partnerships and track her growth and earnings.

Terry

Terry is the marketing director at a boutique clothing brand looking to gain exposure and promote its products through social media. He often browses through Instagram looking for established profiles whose style and visual aesthetic would suit their brand. He wants to contact influencers he likes, set up transactions and track their success simply and efficiently. He would be open to allowing new talent to contact him as long as he isn’t overwhelmed.

DESIGNING USER FLOW

To understand what screens to design and how users would progress through our app it was important that we mapped out the desired interactions we wanted users to have. This was especially important because we were designing for two distinct user groups and we wanted their experiences to be as streamlined and personalised as possible.

I soon realised that the fundamental structure of the “Influencer” and “Promoter” work flow was very similar, they were just performing a slightly different action at each stage. This was a key reason for the ultimately mirrored design of our app, which is expressed through our colour scheme and screen layouts.

ONBOARDING

INFLUENCER FLOW

PROMOTER FLOW

KEY DESIGN DECISIONS

SPLIT APP

Early on in the design process, it was clear we had two distinct user groups who had different motivations for using our app. In our goal to be the bridge for communication between the groups, we chose to completely separate their user experiences. It would allow us to cater each experience more specifically to each user group and better respond to feedback from both groups.

The alternative was to create a unified interface that catered to both groups. In putting together initial sketches of what this would look like, it became clear that especially on a mobile interface where screen real estate was scarce, it was important to make screen content context based. This meant understanding what the user was there for and only providing the necessary information.

Ultimately, I successfully pitched a split app layout despite some initial reluctance from my team members. Our app could be interpreted as two separate apps that shared information, but I used similarities in their workflow structure and consistent design elements to tie them together into a unified visual design.

The colour coding and ‘mirrored’ design was the result of these investigations and a conscious effort to address a potential edge case where a user was both an influencer and a promoter (i.e. they had launched a personal brand). The split app structure reflected this dual identity and allowed these users to keep there respective business goals clear and separate.

Influencers can manage offers they've received or successfully bid for and Promotors can manage the bids they've received for each job they've posted.

Promoters can view the details of a bid and Influencers can view the details of an offer before accepting, rejecting or negotiating.

The Late Mate

Fri, 03 May 2019 00:00:00 GMT

Jinx

Thu, 02 May 2019 00:00:00 GMT

Edinburgh Fringe

Wed, 01 May 2019 00:00:00 GMT

MY ROLE

The Interview was first performed after being selected as Imperial College’s submission to the London Student Drama Festival 2018. It then received support to be the Imperial College Dramatic Society’s Edinburgh Fringe show for the year. I then extended the 25 minute script to 50 minutes with 3 additional cast.

I directed both versions with the help of a co-director, designed and provided the tech for the 6-show fringe run. I also produced the show, managing set transport, cast accomodation and venue hire. In my role as publicity officer was also responsible for designing the publicity material material and social media presence for the show.

SYNOPSIS

In a comic exploration of the disjoint between what we think and what we say, The Interview questions how our actions ultimately influence what we think we deserve. In an interview waiting room. Alex grapples with the sudden appearance of his subconscious as a walking, talking sarcastic bundle of joy. While he waits, the conversation touches on drugs, religion and polygamy, all curiously relevant to Alex’s life. Amidst the little details, he soon realises the interview he is waiting for may not be quite as it seems.

Influenced by the ideas of existentialism and the writings of Jean Paul Sartre and Samuel Beckett, The Interview is an absurdist social commentary on the effects of liberalism on the ethics and morality of our everyday lives. Highlighting the many hypocrisies we happily accept in our personal and professional lives. How can we know if we’re living life right?

PUBLICITY & MEDIA

Cast promotional headshots

Poster and Flyer

DramSoc Publicity

Thu, 28 May 2015 00:00:00 GMT

Life of Andi

Wed, 06 May 2015 00:00:00 GMT

After graduating from university and entering full time work, I found myself with an abundance of free time, a luxury I was not used to. I was able to take up a variety of hobbies like drumming, climbing and social ping pong with friends.

I was also overwhelmed by the realities of adult life, bills and the london rental market to name a few. My navigation of these were unsurprisingly an entertaining mess. So… I decided to document my experiences and the funny thoughts that occured with them in a series of illustrations.

Atarax

Fri, 01 May 2015 00:00:00 GMT

Under the moniker of Atarax, I started this art project on Instagram @ataraxdesign to improve my drawing skills, inspired by the zentangle and doodle art communities on Instagram. Since starting this project five years ago, I have experimented with a large variety of techniques associated with this style, i.e. dotwork, mandala, geometric, abstract and single-line. Starting out, I used black ink pens on white paper, but since then I have amassed a collection of different pens, experimenting with white ink on black paper, watercolour ink and also incorporating digital modifications, showcased in the Mixed Media project.

Mixed Media

Thu, 30 Apr 2015 00:00:00 GMT

After working in black and white for the majority of my drawings in the Atarax Project I decided to combine my desire to incorporate colour with learning new Photoshop skills. The main challenge was the detailed fine lines in my hand-drawn line drawings. Trying to extract clean line art after scanning them proved rather inefficient. I eventually developed a very specific pipeline and wrote a tool to ensure the designs came out in the best format for digital manipulation. I have provided some examples of plain extracted line art and coloured versions.

Overlays

Wed, 29 Apr 2015 00:00:00 GMT

This project is one I took on to improve my Adobe Photoshop skills, while making use of my passion for photography. By experimenting with the overlay effect, this project mixes art and reality to see how shapes and patterns fit into scenes of our daily life. Most of the photographs were taken at locations near my university and my house, places I encounter on a daily basis.

I photographed with a focus on capturing geometric shapes and block colours that would compliment my drawing style when overlaid. The artwork is hand-drawn with black ink pens then post-processed digitally before being incorporated into the photographs.

eReuse

Tue, 28 Apr 2015 00:00:00 GMT

eReuse is a student-run social enterprise that began as part of the Enactus program at the University of New South Wales. As it grew in size and success, its leadership decided to break away from its Enactus parents and cultivate broader partnerships. I was brought on as the visual and graphic designer for the rebranding campaign. I was responsible for designing the new logo, and determining the visual language of our other marketing assets accordingly. This focused on a push for social media content and stickers to be distributed around campus in the lead up to a large sustainability conference we helped organise.

Conference Logo

Promotional Sticker