What do you think of when you hear the term enterprise UX? Designing corporate Human Resources (HR) systems or intranets? Many articles and books for UX professionals focus on designing Web sites and mobile applications for consumers. But what about the silent majority of users in the workplace who are trying to get their job done? Many of them think of enterprise software as the generally sub-par tools that companies force them to use.
However, over the past few years, enterprise UX has started to get more attention from user-experience thought leaders. (There’s even a conference dedicated to it.) But what does enterprise UX actually mean? From what we’ve observed, it seems that there is not yet an agreed-upon definition of this term. This fuels confusion about enterprise UX, why it matters, and what scope it encompasses. Therefore, in our first column on this topic, we’ll
In this edition of Ask UXmatters, our experts discuss the newest discipline within User Experience: DesignOps, which covers the operational aspects of design. Most DesignOps practices have been standard operational practices within software companies for many years—they just weren’t called DesignOps until a couple of years ago, and they did not yet constitute an integrated set of practices.
DesignOps is such a new discipline that the term is still somewhat ill-defined—even though there’s already a conference that focuses on this discipline, the DesignOps Summit, for which 2018 will be its second year, and InVision has just released an ebook on this topic, The DesignOps Handbook. It’s unclear who originally coined the term DesignOps, but there is universal agreement that it was inspired by the term DevOps. This is just the second piece that UXmatters has published about DesignOps. The first was Jeff Sussna’s article “What DesignOps Can Learn from DevOps.”
In this column, our expert panel defines DesignOps, discusses what dimensions the discipline comprehends, and describes DesignOps roles and practices at several leading companies. Read More
The idea of information architecture was what initially attracted me to the field of User Experience some 15 years ago. Working in a small graphic-design studio as the only Web designer for an ad agency, I designed Web sites, often coding them myself. Sometimes, clients sought more complexity in their Web sites. They needed interactions, information processing, and, in some cases, a precursor of customer-relationship management (CRM).
During that period, it occurred to me that, to be successful, Web designers had to do more than just create attractive Web sites. Because we were creating something new, the language of critique that had developed for modern graphic design, which was rooted largely in print design, was inadequate for the work we were now doing. So, in an effort to augment our design vocabulary to describe the new artifacts we were creating, we borrowed some terms from the adjacent fields of industrial design, human factors, and of course, architecture—among many others. Read More
During a project kick-off meeting, my design team was in a discussion with a client when various mental models clashed in the room: “Why should we do that?” “What is journey mapping?” “Why do you need to mention man-hours for doing card sorting explicitly in the UX-effort estimation sheet—and, seriously, what is that?” It became quite evident that it was difficult for our client to understand the meaning and value of UX research. Of course, it would be rather ludicrous for the team to request that the client read about the benefits of UX research. But it became clear that everyone on the project needed a common language and a shared philosophy.
Should your design team dedicate time to UX research—despite the stakeholders and project manager thinking otherwise? How could you convince them of the return on investment (ROI) your client would generate by doing UX research? All too often, when these types of questions arise, teams sacrifice the value that a generative user-research phase would add. Many people think a research phase would be a waste of time and money. However, they are unaware of how user research impacts product strategy—from the conception of an idea to the delivery of the product. To change the mindset of your stakeholders from being naysayers to being advocates for user research, you must help them understand how research can add value to their product and that learnings from user research are an indispensable asset to a product team. Read More
There are many types of deliverables, including presentations, reports and design artifacts such as wireframes, prototypes, and specifications for engineering. It’s not always necessary for a deliverable to show the final version of what a product will look like after being implemented. In many cases, deliverables can be helpful in team decision making, making critiques, and validating designs or identifying the need to make improvements. You need not always strive for perfection.
UX designers focus too much on design deliverables because they are the output of our process, and we want them to look as good and stylish as possible. That mindset usually comes from agencies who sell their services and whose deliverables must make a huge impact to attract and solidify their relationships with their clients. Read More
The first experience people have with your mobile app is the most critical. If they cannot get it working right away, they won’t finish setting it up and won’t come back.
As UX professionals, we often talk about problems with app tours, pound our fists and say “no splash screens,” or discuss the overall onboarding experience. However, there’s still far too little information available about even the basics of designing for security.
Some of the most visible aspects of app security—and those that are most badly done—are registration and sign-on screens. So, in this column, I am going to discuss how to create registration, sign-on, and other related security functions of mobile apps. Read More
Young children communicate well visually. When they want to articulate something for which they simply don’t have words, they point to objects in their environment. When they want more food and their plate is empty, they point to their empty plate or slam their plate down onto the table to signal hunger. They are prompting their parents to visualize what they are asking for. Their parents see the empty plate and know they’ve just finished eating their food. Their child must be asking for more food.
Visuals are effective ways in which to communicate. Sometimes sketching is the fastest way to convey a need or ask a question. According to education professor John Hattie and cognitive psychologist Gregory Yates, people are not all just better visual learners or auditory learners. Lab studies show that people learn best when the stimuli they receive are from different types of media. Our brains are wired to integrate information in different modalities. When we want people to understand something that we are explaining to them, we can reinforce our meaning not just through words, but also through pictures and sounds. Read More
User research consists of two core activities: observing and interviewing. Since we’re most interested in people’s behavior, observing is the most important of these activities because it provides the most accurate information about people, their tasks, and their needs.
While interviewing is also very important, the information people provide during interviews isn’t always accurate or reliable. Often, research participants don’t know why they do things, what they really need, what they might do in the future, or how a design could be improved. To really understand what people do, you can’t just ask them, you have to observe them.
But exactly what is observation, and what does it entail? Though we all know what the word observation means and everyone knows how to look and listen, there is more to it than just pointing your eyes in a particular direction, listening, and taking notes. By doing a little research, I found many books and articles about interviewing, but surprisingly few about how to observe research participants. So, in this column, I’ll first explore what observation is and the different types of observation methods, then focus on one particularly useful, yet underused UX research method: naturalistic observation. Read More
The adoption of iterative product development has required teams to make time-boxed decisions, iterate quickly, and pivot as necessary. At Rockwell Automation, where I work, we transitioned some of our product-development projects to SAFe (Scaled Agile Framework) agile development about three years ago, and we’re continually trying to improve the efficiency and quality of design and engineering across teams. Within the context of our adoption of agile, we’ve piloted a collaborative approach to UX design.
Rockwell’s next-generation products leverage common user-interface (UI) components across products. However, some level of design revision is necessary for each feature that ships. So User Experience supports product teams from an early, evaluation stage. Read More
As UX researchers, we have a great variety of tools and methods that are available to us. However, at times, a project’s scope, timeline, and budget limit our choices. Therefore, we may need to get creative and come up with a new method that both fits the business criteria and helps us discover usability issues.
In this article, I’ll describe how I combined a software-development technique—pair programming—with usability testing on a recent, exciting project at a smart-lighting company for which I was the usability engineer. The project had a very tight deadline. One of my tasks was to test the user experience of a mobile app called Casambi, a remote-control app for smart lighting, which is shown in Figure 1. Read More