hfng - Fotolia
UX guidelines for people-friendly software
Nail these UX design concepts for easier transitions from requirements to application design to code.
Nothing is as straightforward and yet, as inscrutable, as how to deliver on the software demands of the end user. UX designers specialize in the fine art of getting inside a user's mind, but developers and testers also must focus on UX design concepts to produce software that hits the mark.
Most UX design projects are not brand-new applications, which means user requirements can align with -- or come into conflict with -- existing backend database structures, APIs and software dependencies. Integration with external software, repositories and management tools could matter as much as the project's internal code. From this tangle of demands, wants and realities, the development team must create intuitive UX experiences without overrunning the budget or release date.
Two design experts share UX guidelines from the requirements phase through model building and workflow characterization, as well as how they keep application owners, developers and testers communicating and informed throughout the project.
UX design concepts start with requirements, where the software team endeavors to understand the user's functional needs as well as how the program will fit into their lives.
To gather requirements, UX designers make contextual inquiries, where they interview and observe the user. Options range from remote or in-person conversations to job shadowing: Where the UX specialist observes the devices in use, whether the subject stands or sits while they execute the task, the environment and other factors, said Máirín Duffy, senior principal interaction designer at Red Hat, a software company owned by IBM. She encourages researching beyond direct user interactions as well -- if the program supports a given job, learn about the industry and its major trends and challenges.
It's not just about what the software should do, Duffy said, in a presentation on UX guidelines at DevConf 2019 in Boston. Figure out if they use the program for entertainment or for business, or something else. With that information, now gear the design for efficiency, for stickiness or another goal, like loyalty.
Experts caution designers to look beyond technology choices in design decisions. Michael Faulise, managing partner at tap|QA, a QA consultancy and staffing company in Minneapolis, shared the example of a healthcare payer application, with a majority of users over the age of 70.
The healthcare app's older user base prefers live support over chat functionality, so the team should work on integration with a phone system rather than create a sophisticated chatbot. Both technologies give the end user access to information about their healthcare, Faulise said, so it makes sense to initially focus the budget and development on the one with the highest user satisfaction. Faulise co-presented a session on this approach, called "How Design Thinking Will Change QA Next Decade" at STARWEST 2019 in Anaheim, Calif., with Anne Hungate, president of Daring Systems consultancy.
Model the UX
UX guidelines start with user expectations and project goals, which the team must convert into a model. "The model helps you understand the abstract thing that you're building, and should represent how the software will work," Red Hat's Duffy said.
The UI is full of interactions, with data, plugins and other components that Duffy says to arrange as artifacts. Define all of these artifacts and their relationships, hierarchy and expected lifetime.
Organize the tasks in the apps by user actions, and put the tasks in context. Depending on the product, some tasks are private while others are public, and some feeds should be chronological while others are prioritized. Duffy gives the example of social media -- public, prioritized by an algorithm -- versus a chat window -- chronological and shared by a closed group of two or more.
She recommends concept maps, also called mind maps, at this stage in UX design. A mind map is a symbolic diagram of components and the relationships between them, generally radiating out from a central concept.
Picture the workflow
Once the user experience model comes together, design thinking begins to shape development tasks.
As feature development begins, put UX at the forefront, Duffy said. Delineate the integrations -- with software and even physical devices -- necessary for the user to complete a workflow. List the options and tasks for each stage of the workflow.
UX guidelines include the best approach to bring the user from point A to point B. For example, users will abandon a 40-field form, but will complete a five-page form with eight fields per page, tap/QA's Faulise said. "There are psychological principles around human-computer interaction that influence how we design an application," he explained.
While software development that is dictated by user comfort and motivation sounds daunting, there are established patterns from which to draw. Duffy said, examine other tools that complete similar tasks, and check out the design a mass-market tool offers to its wide range of consumer types. Follow common graphic design rules, such as using the color red to draw attention to an element, Faulise pointed out.
Document and communicate design
One of the most difficult aspects of UX design -- and an area with few guidelines -- is communication throughout the project.
Firstly, work from a common terminology that designers, developers, testers and application owners use. Cheat sheets of terms and definitions are easy to make and share.
Diagrams and other visual elements provide a clear picture of the eventual product. Presentations, boards with colored paper notes on them, and visual wireframes all help crystallize a vision. Imagery is also the quickest way to call out poor UX, Faulise said, in things like long dropdown lists or glaring colors. Written documentation also helps keep projects on track.
Collaboration and communication mean talking -- a lot of talking. Long, even repetitive discussions reveal the holes in a design. Ask what-if questions with users and developers throughout the project. Duffy recommends that the UX leader summarize each discussion and confirm the outcome with all parties.
Develop and test in the real world
UX design doesn't exist in a vacuum, so UX guidelines must extend to and embrace legacy codebases, risk vs. reward and a new role for QA.
For most UX projects, there's a preexisting codebase, and in many cases the back-end implementation of the application is off limits in the UX designer's mind, Duffy said.
However, she argued that some changes that require back-end refactoring or updates are worth the effort. Outline the best possible UX, then decide where you can compromise for back-end stability and project scope, and where to push for change.
Quality assurance and testing cannot hinder release velocity for modern applications, which means usability testing has to change. Rather than test usability in staging at the eleventh hour, with a mix of technical and business folks, make user experience part of every sprint, Faulise said. Create objective metrics to quantify user experience, such as clicks per task and time per form, and have QA professionals evaluate if the workflow fits the stated requirements.
User experience is not always the highest priority for app designers, who must work within the product owner's risk tolerance and release schedule, Faulise said. In each design project, usability, security and reliability have weighted values. QA's job is to understand requirements and put checkpoints, tools and processes in place to test features and functionality against a quality baseline.
Finally, UX design concepts don't follow a linear progression. In real application projects, the work is fluid, Duffy said. You'll move through research, modeling and mockup stages a lot.