Education
I completed my MSc in Human-Computer Interaction with Ergonomics. The course provided the foundation for a career in user-centred design.
Employment
After completing my MSc, I joined an engineering consultancy as a Human Factors consultant. I began working in multi-disciplinary design teams. I worked in defence, nuclear, and rail. I worked on both physical and software Ergonomics projects.
I also worked on safety assurance projects, which benefited me. I gained much from the rigorous approach that I needed to apply on these safety projects. This influenced the way I frame my Human Factors work.
Practice
I would describe my practice as varied. I have worked on projects that focus purely on physical Ergonomics. I have worked on projects that focus purely on software Ergonomics. I have worked on projects that integrate the two. For example, I have worked on projects where the organisation procured software systems from different suppliers, all of which we need to physically integrate onto the desks in a control room. I have also looked at the user experience of wider systems, paperwork, procedures, and so forth.
My practice is highly evidence-based. I base my recommendations on the best evidence, drawing on the literature from Ergonomics, Human Factors, HCI, and so forth. If I make a recommendation, I map it back to the relevant literature, or to the relevant standard clause. I read extensively. I trawl through the literature in this space. I collate what I find into an Excel-based commonplace book. I capture key insights from research, standards, guidance, and so forth. Before I kept a commonplace book, I used to lose track of key sources that I would come across. If I then encountered a similar problem where this source would also prove useful, I would have to search for it again from scratch. Keeping a commonplace book helps me to work more efficiently.
Analysis
When it comes to analysis, I like to be creative. For example, I create my own spreadsheets to find different patterns in the data I collect about systems. I also like to combine analytical methods to create something more robust. This helps me to understand a given situation from more angles. I have done this when I have looked at the risk of use error with user interfaces.
Evaluation
When it comes to evaluation, I like to stick to tried-and-tested methods. For example, when it comes to collecting quantifiable subjective user data, I prefer to stick to the likes of the System Usability Scale and the Single Ease Question. They are well-validated questionnaires, underpinned by research. If there is however a gap between what we need on a project and what is currently out there, then I would look to develop my own questionnaire.
Design Practice
In my experience, the degree to which you engage in these design practices depends on the project. It usually is a mixture, but the mixture of each form of design practice will vary by project. For example, on projects with greater amounts of uncertainty, I will need to use more trial and error to work through the assumptions.
Design Problem
As an example of a design problem that I have encountered, I have worked on projects where the project has procured software, but we cannot change certain elements of the software because it is core to the product. These elements may not be ideal or the “gold standard” from a Human Factors perspective. However, we must nonetheless find a way to make it work.
As another example of a design problem that I have encountered, I have worked on projects which involve bringing multiple software user interfaces into use, which a given operator needs to use. Therefore, to minimize the risk of negative transfer, these software user interfaces need to be compatible with each other when it comes to the user experience.
Systems Perspective
It is important to take a systems perspective. It is important to look at the whole environment where a given device needs to operate. For example, when it comes to control room design, you must think about how each control room element will integrate into the control room, from software to hardware to all other elements. Your thinking must extend beyond any one aspect.
Approach
I use the steps from BS EN ISO 9241-210 as a broad framework for my practice, most notably to understand the context of use, specify the user requirements, produce design solutions, and evaluate the design until we reach a fit-for-purpose solution. For each these steps, I use specific approaches that work for me.
When it comes to understanding the context of use, one approach I like to use is Cognitive Work Analysis, and in particular the contextual activity template. I use this to map out all the system’s functions and the different situations that the end-users will encounter. I also use Tabular Task Analysis. I map the user’s tasks out in the subject-verb-object format. I first started using this format after seeing the sentence structure outlined in the book “Guidelines for Developing Instructions” by Kay Inaba et. al (2004). I found this useful as an approach to task analysis. I created a template in Excel that divides up these elements of a user’s tasks in this way. This approach allows me to develop task analysis in a consistent, systematic manner. At this stage, I also like to record an inventory of all the system’s elements. For user interfaces, this would mean recording each user interface screen, and each user interface element. My approach is to collect vast amounts of data, and then narrow the focus down as needed.
User Requirements
When it comes to understanding the user requirements, I apply the relevant Human Factors parameters to the context of use. I compile spreadsheets that contain principles, patterns, guidelines and so forth. I record the source, a link to the source where applicable, and the key insights from the source. I also include keywords to search for. This allows me to filter and search for patterns across what I have collected. It is a commonplace book. I trawl through sources of evidence for anything that could be of help to me. I arm myself with hundreds of principles, patterns, and guidelines. It is then a case of applying the right parameters to the situation.
When it comes to producing design solutions, I like to work up a range of options for solutions, and this is where I will prototype different solutions. For example, I have used PowerPoint to quickly put together interactive user interface prototypes. I like how IDEO’s CEO Tim Brown talks about the need to “build to think.” I like IDEO’s “fail faster to succeed sooner” approach.
Evaluating Design Solutions
When it comes to evaluating design solutions, I assess each proposed design solution against the parameters that I have identified previously. For example, this could involve assessment against clauses from standards, such as consistency of the positioning of controls. This could also involve performance-related parameters, such as task completion rates. This could also involve collecting subjective feedback from users, such as via the Single Ease Question and the System Usability Scale, to capture quantifiable feedback. In addition to this, this could also involve collecting qualitative feedback from users.
Framework
I like to employ the framework outlined in BS EN ISO 9241-210. Specifying the context of use, understanding the user requirements, creating design solutions, and then evaluating these design solutions until you arrive at a suitable solution provides a robust framework for design practice.
Case Studies
I participated in the 2019 BTNG hackathon at the Microsoft Reactor office in London. Microsoft Reactor streamed the event live on their YouTube channel. The hackathon sought to reduce the impact of “brain-drain” in Nigeria, where highly skilled Nigerian professionals leave the country to work in other parts of the world. At this event, I worked in a team with two UX professionals, a Software Engineer, and a medical student. We developed a prototype software app that aimed to improve access to healthcare in parts of Nigeria by connecting them remotely to Nigerian Healthcare professionals working in the diaspora.
We researched the current healthcare situation in Nigeria. We identified huge challenges, both in urban and rural areas. Initially, we wanted to focus our solution on helping people in rural parts of Nigeria. However, issues with literacy, internet access and electricity meant that this would not currently be practicable. Therefore, we decided to focus on urban areas.
We prototyped our solution in Sketch, and the Software Engineer created the app itself in Android. The registration page allows users to add key information to their profile, such as details about their previous medical history. The app allows to confirm whether there is a medical emergency, and in this case, the app connects the user to the relevant emergency health services. For all other matters, the app offers three options to the user. The first option allows the user to look through a directory of common illnesses. The second option allows the user to find nearby health facilities. The third option allows the user to directly connect a healthcare professional (either by phone or via a video call).
This experience provided insights into the infrastructure challenges associated with delivering solutions into this problem space.
Example of Framing Design Practice
I worked on a major control room upgrade project. The project procured new control and communications systems for the operators to use. Different suppliers developed these different systems. This risked introducing inconsistency across these systems.
I took action to promote consistency across these systems. I created a style guide, which mapped out all the key features across all systems and specified the style and format for the suppliers to implement to promote consistency across the systems.
I took a pragmatic approach. I assessed the most developed system against the relevant Human Factors parameters. I then used the features from that system to define the style for the less developed systems to follow. Once the suppliers developed each of the systems, the style guide formed the basis for the integration assessment of all the systems.
My control panel design work is another example of how I frame my design practice. To specify the control panels on a particular project, we worked with end-user representatives to look at the tasks that they need to do with the control panels. We used that information to determine what control and indications they needed the control panel to include. I then developed an interactive PowerPoint prototype of the proposed solution to make sure it met the needs of the users. We then implemented the control panels, developed training guides, and trained users on how to operate them.
Ways Ahead for Framing Design Practice
I can see more conduct and reporting around equality, diversity, and inclusion. We need to use fit-for-purpose methods for this emerging area to enhance the way professionals deliver solutions. For example, in 1993, Jakob Nielsen said that the thinking aloud method is the most important usability method. This will be the case for users who are functionally able to articulate their thinking verbally. However, specific users may struggle with this method, such as people with dementia or aphasia. I expect to see professionals develop more inclusive approaches to design practice, such as further development of multi-modal communication approaches to user testing.
I also expect to see more conduct and reporting around sustainable design, with professional helping to develop better smart technology that will support optimal use of energy.
Additional Points
I also like to build in approaches from other fields. For example, I like Triz (Theory of Inventive Problem Solving), and specifically, the approach set out by Gordon Cameron in his book “Trizics.” It helps me to think about a problem from different angles. For example, there is a tool known as “Nine Windows.” This encourages you to look at a problem at the supersystem, system, and subsystem level. In addition to that, it encourages you to look at a problem in terms of its past, present, and future. This approach is incredibly useful for Human Factors work. It helps me to think more broadly.
References
Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. Harper Business.
Cameron, G. (2010). Trizics: Teach Yourself Triz, How to Invent, Innovate and Solve Impossible Technical Problems Systematically. CreateSpace Independent Publishing Platform.
IDEO (2013). Why You Should Talk Less and Do More. Available at: https://designthinking.ideo.com/blog/why-you-should-talk-less-and-do-more#:~:text=When%20you%27re%20trying%20new,re%20doing%20is%20an%20experiment.
Inaba, K., Parsons, S.O., and Smillie, R.J. (2004). Guidelines for Developing Instructions. CRC Press.
Nielsen, J. (1993). Usability Engineering. Academic Press Inc.