How Research Informs Design

Osama Ashawa at UXDX USA. Video: https://www.youtube.com/watch?v=WBEtdug-TVo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Showing the why behind every design choice

[00:00:00] 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.

[00:00:17] 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 ten years. Our design team owns and drives various creative outputs, from information architecture to wireframing to prototyping to visual designs 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.

[00:00:48] 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 centered around the work and experiences that our team has had making digital applications, and the considerations we commonly make.

[00:01:12] 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. 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 to reference research findings and data to show how we framed our design choices and why they will be most successful.

[00:01:46] Design often works best within constraints. Starting with a blank canvas is a daunting prospect, because there is 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 placed. The questions you ask can generate themes to explore and address. So build an inventory of questions around common themes like people, tools, communication, processes and so on.

How research informs design

[00:02:23] So, how does research inform design? Here's a distilled list of high-level responsibilities or activities, or outputs from research, that directly tie into design. Ultimately design is building off of required functionality or desired outcomes. So product requirements of the solution fulfill this expectation. We need to know what we're going to build, or what the end goal is, what success is[?].

[00:02:53] Next, through most discovery processes, key insights and findings get unearthed 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 design 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.

[00:03:35] To fulfill the research responsibilities just mentioned, some typical research activities we carry out include conducting interviews with users or stakeholders, doing in-situ field observations to observe people's work environments and their behavior, facilitating workshops with a variety of personas and/or stakeholders, and iterative ideation and prototyping to elicit fuller requirements or process insights and improvements.

[00:04:07] While UX researchers typically drive a lot of these activities in many UX organizations, we find that it works well to include designers throughout this process. It helps to view the data and observations through a design lens, to get a sense of how these insights may translate into relevant user experiences or specific experience touch points. The scenarios and the design choices that we'll see shortly are examples influenced or informed by the output of these activities.

People first: personas and experience levels

[00:04:42] Unsurprisingly, we start with people first. What can we find out about the people that will be using our designs, or the tool that we're building for them? How do the needs of each user group differ or overlap? What are the different user groups that are participating in or utilizing this tool or this experience? Thinking about what opportunities we can find to design for each user's specific perspective, or for their business or their work, would be a good approach to take.

[00:05:22] One way we can do this is by utilizing 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 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.

[00:05:45] Some ways this has informed our design strategy and UI is to present reference materials, such as manuals or procedural documentation, in context to the work being performed by, say, a junior level technician. 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.

[00:06:17] But we don't want to forget about the experienced persona, or a pro user, or the quick learner. An intuitive enterprise can help users become proficient in its use. There may be opportunities to design shortcuts for faster interactions, or minimize the amount of information presented to reduce cognitive load and improve focus and speed.

Workflows and shared processes

[00:06:43] I want to get into workflows a little bit. By knowing each user type's workflow we can prioritize, or emphasize and de-emphasize, the content in the application, or simply only show what each user needs. For example, executives may only need business level data and analytics for business tasks outside of the application. And managers, that need to organize teams, plan tasks and schedules, assess performance, all likely and more in more content-dense views and interfaces, may need more interaction and more dense views to look at.

[00:07:25] Then you have the field operator or the technician. They may have a job-specific focus that requires a linear approach to their task, 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 varied functionality across those different user workflows or user types, and still provide a cohesive experience across each of those groups.

[00:07:59] While each user type that we just discussed may have their own independent workflows, it is not uncommon for them to interact with each other, have shared or overlapping processes. Managers may frequently exchange on the work of their technicians for things like approvals, statuses of submissions, and work reviewing and editing.

[00:08:28] 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 it adds time to the overall workflow, it can introduce confusion and create bottlenecks.

[00:08:56] In this example I'm showing here, we were tasked to modernize and improve a workflow for a call center and their agents handling things like customer retention. This meant we were dealing with people that had issues with their account service, or they wanted to end their business with the company. A common problem or frustration or discomfort that was identified for the call center application's workforce was dealing with the problems of the systems. 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 organized.

[00:09:40] That would create moments of awkward silence, it would create frustration with the people waiting to settle their dispute. And we noticed a small opportunity there to build a connection and take the edge off. Not all insights lead to tangible UI that will address a problem, but in this case, just being able to pull in information about the customer's location, and things about the weather, landmark images of where they're living, gave an opportunity for the call center agent to make 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 for those call center agents.

Getting into their world: language and culture

[00:10:41] Another thing is, we've got to get into their world. In this next set of examples we'll look at some of the environmental factors and observations and insights that led to specific design choices and approaches. Language and culture can be interesting within a specific group. Learning about our user groups can reveal nuanced findings and insights.

[00:11:07] This watch example shown here contains a set of uniquely designed symbols specific to this organization's process. Our user group was military based. They all came from the military. They worked in security for the company that we designed an application suite for. 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 helped them transform or digitize their process, from paper and clipboard and PDFs to a fully interactive mobile and wearable and tablet-based solution.

[00:11:57] What we learned in observing them and understanding just their language and specific behavior to their process was, they would often make gestures like circling 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, or culture and their process. So we decided to bring that into the digital space 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's double checking that, understanding where they are in the process. So we included that.

[00:12:52] Another thing related to this project, related to the language of the culture, is we used very specific iconography and symbols that were inspired by and referenced NATO symbols for iconography. That's because the group, being of a military background, were familiar with those icon sets and that visual language. 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 the people that are using your work, or using your designs, speak out and defend it.

[00:13:57] Another thing with language and culture is, there's some language and culture that you can encounter that can be motivating for you not to mess up. For instance, we were designing and developing a tablet inspection application that would be used on oil rigs out in the ocean. 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." Basically what that meant was they would chuck the device, the iPad, overboard, and for us, it better hope it floats. So we knew at that point there was no option to fail, and we needed to really focus on the success and the effectiveness of the solution. Just a little color commentary there from what you might expect here in the field, and how that can influence your design approach.

Motivating behavior and supporting business goals

[00:15:09] Part of the approach of improving user experience often includes motivating behavior and adjusting behavior. We may practice or advocate for user-centered design, but that isn't at the expense of fulfilling or supporting business goals and initiatives.

[00:15:28] In one project, an application suite that supported industrial craftspeople, so things like painters, fireproofers, welders, scaffolders working in industrial sites, this application supported people with things like hiring, job or gig placement, career progression. The business needed to ensure that their workforce adopted the application, but they also had goals of improving user engagement alongside the adoption.

[00:16:05] So through workshops, a roadmap for the company's store and incentives was born. Leveraging gamification and achievements based on milestones and performance metrics, we designed a system of rewards and collectible trophies. We referenced things like the Nike sports application, which gave you trophies and showed you progression, and just other things we observed people having interest in, in this group, and also things that could be more motivating for them, participating in adopting aspects of this application.

[00:16:44] But we also suggested to include real-world prizes in the form of discounts and free merchandise from the store, which was all well received. So it incentivized people to use the application and to contribute content, contribute data, which all helped toward the business getting a better picture of their business and of their workforce, so they can make more strategic recommendations.

Form factors, gear and environment

[00:17:16] Continuing with the business theme, in one case we encountered a scenario where the business purchased a thousand 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 best for a 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 if your user group is mostly mobile, working with multiple monitors, switching between desk and field context. All those could impact what kind of form factors you incorporate.

[00:18:04] And then next, gear and peripherals. When you go into the contextual inquiries and you observe gear and specific devices being used, gear can cause cumbersome experiences with devices. We encounter a variety of safety gear and scenarios: helmets, goggles, ear protection, safety harnesses. That can impact whether a touch interface is going to be successful or not, or what kind of adaptations need to be taken. Peripherals are sometimes just part of jobs. You may encounter scanners, attached devices, labels, chairs, calculators, that sort of thing.

[00:18:42] Environmental factors are also important. Things like light, sound and noise can have specific design constraints or necessities. Understanding the environment of your users can help avoid harmful experiences. 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 to the user. You can imagine, late at night you don't want a bright interface shining in your eye, because that messes with your night vision.

[00:19:14] 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 to alert the user.

Tech, data and emerging technology

[00:19:31] And then, don't forget about things like tech and data. 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 displayed in applications. Users don't always use the data that they have 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.

[00:20:13] Contextual data can be used to create suggestions for the user. An example: Waze senses you slow down and starts bringing up some menu prompts for, if 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 optional routes.

[00:20:48] 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 useful to keep the user properly informed: showing whether connection is lost, showing a timestamp of when data has been refreshed. But consider how the UI needs to change if the application's offline or there's missing data. Things like loading skeleton UI when dealing with slower servers or performance issues can be one way to mitigate the sense of waiting and the pain point around that.

[00:21:35] And then to round out the tech discussion, considering emerging technology: look for opportunities, but don't force it. Things like voice assistants and smart commands can be tailored to your application's functionality. Think about common phrases or language specific to your users and their work, to promote familiarity when digitizing a workflow. Things like AI and machine learning is another emerging tech that could be used to automate and enhance UX and workflows. It's best to test these out, but take the opportunity and see if there's a way to improve an experience.

Research after the designs are made

[00:22:15] Last, I wanted to talk about some of the ways research informs and affects design when design has been completed. We'll take a look at how research informs design after the screens and solutions have been created.

[00:22:34] In the wireframes and prototypes stage, research can provide heuristic evaluation of the designs. They can help to ideate on UI patterns and intended actions and requirements. Use prototypes for user testing and provide corrective notes for further iterations: things like content verifications, gesture interaction assessment, and hierarchy of content and tasks.

[00:23:01] And then finally, on the visual design side of things, it's one of the more subjective moments of user interface design, but visuals should be reinforcing 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 phase and earlier design phases. Research can also help to validate the visual language, things like iconography, color schemes, imagery and those sorts of things, with user groups.

[00:23:35] 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 to just say hello. Thanks, and enjoy the conference.