How Research Informs Design

Hello, and thanks for taking an interest in this talk. Today I wanted to share some experiences and considerations about how UX research can inform UX design to help drive successful strategies for product design teams. I hope you find it helpful. So let's get started.

My name is Osama Ashawa. I'm a lead UX designer at ChaiOne. I've been designing user experience solutions for enterprises and industrial companies here for the last 10 years. Our design team owns and drives various creative outputs from information architecture to wireframing, to prototyping, to visual designs and design sounds and usage guidelines. We work hand in hand with our research team. And I hope to show how that has benefited our work and benefited our clients. So it's important to recognize that user experience is more than just the thing people interact with. It encompasses all five senses and can oftentimes affect our emotions. The points I want to share today will be centred on the work and experiences that our team has had making digital applications and the considerations we commonly make. So if you're a designer, I'm willing to bet that you've been asked to make it pretty. It's not uncommon to fall into the trap of subjectivity.

So when we as designers present our work to clients or stakeholders, we should plan to show the why behind every design choice. It's not good enough to say this looks best or this is a best practice. Instead, we're more benefited from referencing research findings and data to show how we framed our design choices and why they will be most successful. So design often works best within constraints. Starting with a blank canvas is a daunting prospect. Because there's an infinite number of ideas to attempt. So designers are well served to ask a bunch of questions to get started. And more importantly, they need answers to those questions before a pixel is ever replaced. The questions you would ask can generally generate themes to explore and address. To build an inventory of questions around common themes like people tools, communication processes, and so on. So how does research-informed design? Well, here's a distilled list of high-level responsibilities or activities that are outputs from research that directly tie into the design. Ultimately, design is building off of required functionality or desired outcomes. So product requirements of the solution fulfil this expectation. Right, we need to know what we're going to build or what the end goal is, and what success is. Next, through most discovery processes, key insights and findings get on earth that, both directly and indirectly, translate into user interactions and design patterns. Then, throughout the design phase, as well as after product releases. User testing helps to validate whether or not a designer is successful and as a way to document UX or functional issues so that they can be addressed in subsequent releases or create additional requirements or opportunities for future software.

So to fulfil the research responsibilities just mentioned, some typical research activities we carry out include conducting interviews with the users or stakeholders, doing Institute field observations to observe people's work environments and our peer facilitating workshops with a variety of personas and or stakeholders, iterative ideation and prototyping to elicit fuller requirements, or process insights and improvements. While UX researchers typically drive a lot of these activities and many UX organisations, we find that it works well to include designers throughout this process. It helps to view the data and observations through a design lens that gets a sense of how these insights may translate into relevant user experiences or specific experience touchpoints. So the scenarios and the design choices that we'll see shortly are examples of waste influenced or informed by the output of these activities. So unsurprisingly, we start with people first. What can we find out about people that will be using our designs or the tool that we're building for them? How did the needs of each user group differ or overlap?

What are the different user groups? As that is participating or utilising this tool or this experience. So, thinking about what opportunities we can find for designing for each user-specific perspective or a business, for their business or their work would be a good approach to the table. So one way we can do this is by utilising personas and understanding the roles involved. Personas can provide a lot of information and demographic themes to consider. For instance, experience level is something we'll look closely at in the enterprise and industrial work we do. It isn't uncommon for our typical user base to consist of employees with varying experience levels. Some ways this has informed our design strategy and UI is to present reference materials such as manuals or procedural documentation in context to work being performed by, say, a junior-level technician, right, they don't have as much extensive training, so they may need to refer to manuals more often. So we can supplement that experience and surface that information as they're working through it. As they would be more likely and, in most cases, observed to reference the documentation so they can complete their tasks. But we don't want to forget about the experience, the experience persona or a Pro user, or the quick learner, so an intuitive interface can help users become proficient and its use. There may be opportunities to design shortcuts for faster interactions or minimise the amount of information presented to reduce cognitive load and improve focus and speed. So I want to get into workflows a little bit. By knowing each user type workflow, we can prioritise or emphasise and de-emphasize the content and the application, or simply only show what each user can see. For example, executives may only need business-level data and analytics for business tasks outside of the application. And managers that need to organise teams plan tasks, and schedules assess performance, you know, all likely and more. In more content, dense views and interfaces may need more interaction and more dense views to look at. Now, then you have the field operator or the technician. They may have a job-specific focus that requires a linear approach to their tasks. So you want to reduce the cognitive load outside of accomplishing that task. Knowing this type of information lets designers make scalable or modular systems that can accommodate the range of data density and vary functionality across those different user workflows or user types and still provide a cohesive experience across each of those groups.

So while each user type that we looked at or just discussed may have its own independent workflows, it is not uncommon for them to interact with each other and have shared or overlapping processes. Managers may frequently exchange the work of their technicians for things like approvals, status, statuses of submissions, and work reviewing and editing. So we commonly see business processes involving users communicating via email to exchange information on the shared deliverable. This gets to become a mess. People don't know. They're searching through tons of emails. And they're not always including the people involved in this process. So you can expect that there's it adds time to the overall workflow, can introduce confusion, and create bottlenecks. So in this example, I'm showing here, we were tasked to modernise and improve a workflow for a call centre and their agents handling things like customer retention. This meant we were dealing with people that had issues with their accounts service or who wanted to end their business with the company. A common problem or frustration, or discomfort that was identified for call centres, applications, and the workforce was not having anything was dealing with the problems of the system. So the system would be really slow. It would take a lot of time to pull up customer records to find the information because it was poorly organised. And so that would create moments of awkward silence. It would create frustration with the people waiting to settle their dispute. And there was, we noticed, a small opportunity there to build a connection and take the edge off. So not all insights lead to tangible results.

A UI that will address a problem. But in this case, just being able to pull in information about the customer's location, and you know things about the weather, landmark images of, you know where they're living created, gave an opportunity for the call centre agent to talk. Some made some small talk with the customer while the system was retrieving their information. This surprisingly played really well in our user tests and improved the success of those call centre agents. The next thing is, we got to get into their world. So in this next set of examples, we'll look at some of the environmental factors and observations, and insights that lead to specific design choices and approaches. Language and culture can be interesting within a specific group. Learning about our user groups can reveal nuance findings and insights. So this watch example, shown here, contains a set of uniquely designed symbols specific to this organisation's process. So our user group was from a military base. They all came from the military. They worked in security for the company where we designed an application suite. And they had a current process of checking in the vehicles that were entering a facility. And they had a very specific security procedure to follow. We help them transform or digitise their process from paper and clipboard and PDFs to a fully interactive, mobile and wearable, and tablet-based solution. What we learned in observing them and understanding just their language and specific behaviour to their process was they would often make gestures like circling the step, the security step that they were conducting, and once it was completed, slashing through the circle.

So we understood this to be a familiar gesture, a familiar interaction, and a familiar sort of language in their process. So we're culture and their process. So we decided to bring that into the digital scape and have them carry out the same gesture to complete a task so that you wouldn't lose that sense of security and knowing that you've accomplished a task. And everyone is double-checking that understanding of where they are in the process. So we included that. Another thing related to this project is related to kind of the language of the culture. We use very specific iconography and symbols that were inspired and referenced by NATO symbols for iconography. And that's because the group being military has a military background. We're familiar with those icon sets and that visual language. So it came to the surface when a stakeholder who was pretty removed from the project had confusion around these symbols and was questioning whether they made sense when a subject matter expert who was familiar with the project, familiar with the team using it and the process, spoke up for us and basically told them no, everyone on the team knows exactly what these things mean. So it is designed for this team for this group. And it's always nice to have them, you know, the people that are using your work, or using your design, speak out and defend it. And another thing with language and culture is you might. There's some language and culture that you and you can encounter that can be motivating for you not to mess up. For instance, we were developing a designing a tablet inspection application that would be used on oil rigs out in the ocean. And one

One stakeholder or potential end-user, during a prototype test, mentioned that if this thing takes longer than the current method, meaning the paper process that they're used to, I hope it'll pass the float test. And basically, what that meant was they would check the device, the iPad overboard, and you know, for us, you'd better hope it floats. So we knew at that point that there was no option to fail, and we needed to really focus on the success and the effectiveness of the solution. So just a little kind of colour commentary there from what you might expect here in the field and how that can influence your design approach. Okay, so part of the approach to improving user experience often includes motivating behaviour and adjusting behaviour. We may practice or advocate for user-centred design, but that isn't at the expense of fulfilling or supporting business goals and initiatives. And one project and application suite that supported industrial craftspeople, so things like painters, fire proofers, welders, scaffolders, working in industrial sites.

This application supported people with things like hiring, job or gig placement, career progression, and the business needed to ensure that their workforce adopted the application. But they also had goals of starting up a kind of building of improving user engagement and, and alongside that adoption, so through workshops and a roadmap for the company store and incentives were born. Leveraging gamification and achievements based on milestones and performance metrics, we designed a system of rewards and collectible trophies. We reference things like the Nike application, sports application, which gave you trophies and showed you progression, and just other things people we observe people having an interest in, in this group, and also things that could be more motivating for them participating in adopting elements aspects of this application. But we also suggested including real-world prizes in the form of discounts and free merchandise from the store, which was all well received so incentivizes people to use the application and to contribute content, contribute data, which all help toward the business thing, getting a better picture of their business and have their workforce, so they can make more strategic recommendations. So, continuing with the business theme, in one case, we encountered a scenario where the business purchased 1000 new iPads and wanted a solution to take advantage of them. This meant we were forced into a tablet form factor regardless of whether it was the best tool for the workforce. Thankfully, we were able to show the value of expanding the devices for the product by assessing the form factors currently being used and examining opportunities for mobile and wearables.

So consider your user group mostly. Consider if your user group is mostly mobile, working with multiple monitors, and switching between desk and field contexts. All those could impact what kind of four factors you incorporate. And then next gear and peripherals. So when you go into contextual inquiries, and you observe gear and specific devices and use gear can cause cumbersome experiences with devices, we encounter a variety of safety gear and scenarios, helmets, goggles, ear protection safety harnesses. So that can impact whether a touch interface is going to be successful or not or what kind of adaptations need to be taken. Peripheral peripherals are sometimes just part of jobs. You may encounter scanners attached to devices, labelled tours, calculators, that sort of thing. All right. And then environmental factors are also important things like sound and noise can have specific design constraints or necessities. Understanding the environment of the users can help avoid harmful experiences. So light to dark UI transitions based on time is one example of understanding the impact of interfaces adapting to an environmental condition and easing the physical effects on the user. You can imagine late at night. You don't want a bright interface shining in your eyes because that messes with your night vision.

In one scenario, we observed users working in noisy environments with handheld devices notifications were important. And so, we made sure to accompany them with haptic feedback to increase the chance of alerting the user. All right. And then don't forget about things like tech and data. So sometimes tech and data create hard limits, but they can also offer cool and effective opportunities for solutions. Available data is something you need to consider. Knowing what data is available directly impacts what content gets to put displayed in applications. Users don't always use the data that they have active access to. Sometimes it's difficult to find, and sometimes it's difficult to present and consume. Sometimes we learned that users didn't even know certain data existed. So that creates an opportunity to help them and provide information that's useful to them. Contextual data can be used to create suggestions for the user. So an example Waze, has consensus, slow down and start bringing up some menu prompts for, you know, do you want to add that there's an accident? Or are you in traffic? You can verify this helps improve the experience for the company to better provide accurate information but also, it reinforces that it's understanding your current situation and provides you some, you know, optional routes. Alright, so it's not uncommon that we'll encounter performance issues and have to work around that. Knowing the reliability and freshness of information is often critical to users. Visual cues can be used to keep the user properly informed, right showing whether connections were lost showing the timestamp of when data has been refreshed. But consider how the UI needs to change if something is if the application is offline or there's missing data.

Things like loading the skeleton UI when dealing with slow, slower servers or performance issues can be one way to mitigate the sense of waiting and the pain point around that. And then to round out the tech discussion. So considering emerging technology, look for opportunities, but don't force it right things like voice assistants and smart commands can be tailored to your application's functionality. I think common phrases are language specific to your users and their work for their work to promote familiarity when digitising workflow. Things like AI and machine learning are other emerging tech that could be used to automate and enhance UX and workflows. It's best to test these out, but you know, take the opportunity and see if there's a way to improve an experience. Alright, so last, I wanted to talk about just some of the ways research informs and affects design. When a design has been completed, so things are, you know, we'll take a look at how research informs the design and after the screenings and solutions have been created. In the wireframes and prototypes, stage research can provide a heuristic evaluation of the designs. They can help to ideate UI patterns and intended actions and requirements. Use prototypes for user testing and provide corrective notes for further iterations, things like content verifications, gestures, interaction, assessment, and hierarchy of content and tasks. And then finally, on the visual design side of things, you know, it's one of the more subjective moments of user interface design. But visuals should reinforce the interaction and the functionality, knowing about how our user groups may identify specific vision impairments or conditions to account for when you get into this space and earlier design phases. Research can also help to validate the visual language things like iconography, colour schemes, imagery, and those sorts of things with user groups. So I hope this introductory talk gave you some insight into the influence research outcomes can have on specific design approaches and implementations. Thank you for your time. Please feel free to reach out to me via email if you want to continue the discussion or share your own insights and experiences or just say hello. Thanks and enjoy the conference.