UXD Jobs News & Events

Publish your UX related news & events. Mail to publish@uxdjobs.com.



The Grid System: Building a Solid Design Layout

Now that we’ve seen some grids at work in the Rule of Thirds article, let’s examine them a little more deeply. As a concept that deals so fundamentally with the fabric and background of our work as designers, it’s easy to overlook the power of grids and think more about the elements we want to create. Many traditional artists still paint their masterpieces over a feint series of intersecting lines. To help us make the most of our work surfaces and create with precision, we designers have a tool that echoes this. We call it the Grid System.

The Story of the Grid

One of the easiest ways to achieve an organized design is to apply a grid system. It’s a tried and tested technique that first found favor in print layout. Low-tech and cheap, this is a great resource for you as a designer – consider it a top-ten tool in your office. Grids in interactive design can also help provide a consistent experience across multiple devices with different screen sizes. Users are happy when they see familiar features laid out as they would expect to find them.

The grid system helps align page elements based on sequenced columns and rows. We use this column-based structure to place text, images, and functions in a consistent way throughout the design. Every element has its place that we can see instantly and reproduce elsewhere. Consider the grids we find in maps. Islands, towns, lakes will appear on an exact part of a map, on a set of North-South/East-West coordinates. They will always appear in the same place on other maps. A GPS accesses these coordinates to help guide us; imagine the chaos if there were no grid system for it to latch on to and keep us right on the road!

The grid system was first used to arrange handwriting on paper and then in publishing to organize the layout of printed pages. Given that the printed page and the virtual page have much in common,it should come as no surprise that we also use it in web and app design. Creating a grid system for the virtual page is a little more complex than for the physical page – browsers handle information differently, and screens vary in size.Happily, however, the principle remains the same.

That’s not to say that there’s no resistance to using the grid system. Some designers feel that the grid limits creativity. While this may be true, it’s important to recognize that many designers employ the grid system regularly because it is so effective at organizing information.

The best layout is one which provides no distraction from the content. Thanks to its mathematical precision, the grid system is a great example of this kind of layout.

Grid as a Design Principle

Villard De Honnecourt, a 13th-century French artist, merged the grid system with the golden ratio to produce printed page layouts with margins based on fixed ratios. That methodology continues to the present day, as the majority of printed books and magazines prove. Publishers, editors and designers place so much effort on keeping the tradition, not only because it’s known to be the best way but for another large reason. The readers (i.e., the users) expect to find everything in its proper place. Remember, the human eye is drawn to elements; it is also easily upset if it is confused or made to work out a problem it was not expecting to encounter.

 

Let’s try a quick experiment to see just how effective a grid can be. If you have two blank sheets of paper handy, draw about four or five shapes at random on one of them. Don’t worry about neatness and geometry – it’s just a simple illustration. When you’re finished, try to copy them as they appear on the second blank page (please don’t “cheat” by putting the second page under the first and drawing over the shapes again to trace them). Even if you have a very sharp eye and sure hand, you’ll notice that it’s practically impossible to replicate the first design, with everything appearing in the same place.

The second part of this experiment is optional, but it will help to drive home the point. If you have squared or graph paper lying around, take two pages and repeat the procedure. Do you notice how copying your original is so much easier when you can guide your hand? The grid made by the intersecting lines of this special paper gives us the gift of making truly accurate copies. By training our eye on the number of columns across and rows down, we can duplicate in free hand almost as perfectly as a photocopier.

The image at the top of our article illustrates the components of the printed page: a header, footer, as well as right and left margins. Inside the margins, a designer has created equal-sized columns with a space between them, known as a gutter. Knowing that the page can include one or more columns, the designer can place elements such as images and text within these columns to provide alignment with the rest of the content. The image and paragraph areas may overlap in one or more columns.

Similar to the way in which vertical grid lines create these useful columns, horizontal grid lines guide the height of elements in the design. These portions of the grid are known as rows. As designers, we want to make the height of each row as a proportion of the width of the columns. For example, the ratio of column width to row height is 3:2, 4:3, etc.

Notice how we arrange the rows equally within the page layout, and how we insert gutter space between each row. We can then place elements of the page content in one or more rows, as shown in the figure at the top.

Grids in Interactive Design

In the digital world, the grid system acts similarly to the print layout in organizing the elements on the page. Additionally, it provides a guide for designers to create multiple layouts that support responsive themes for different screen sizes.

We divide the web page layout into columns that we separate with margins, using whitespace, between them. The width of the columns and the margins are equal, and we can place content in one or more columns based on the layout of the design.

The application of a grid means that the design can be divided into multiple columns that can help designers organize content. For example,we can have one, two, three, six, twelve, or more columns. Today’s screen resolutions reach very large sizes compared with what was available in the early days of computers. Even so, using a 960-pixel width can ensure that the design is properly displayed on many computer screens. It can also help designers modify the layout for mobile devices.

The examples above show grid systems that are based on the 960-pixel resolution from http://960.gs, which provides a useful guide for building your own grid-based web layouts.

There are other helpful tools for building grid layouts available online, too:

  • http://1200px.com/1200px: This website helps you build a grid system for much wider website designs than the 960-pixel style.
  • Golden Grid System: This website can help you build a grid system and optimize it for mobile-responsive display.

If you want to explore further grid systems for different purposes, you can find some at the following websites:

The Take Away

The Grid System has been helping artists of all types (including writers) for a long time. First utilized by a 13th-Century artist, who merged it with the golden ratio, the grid system has been a tried, tested, and trusted methodology for centuries. It firstly empowered writers to position their handwriting neatly on paper; later on, it became a universal standard in the publishing industry. Publishing houses everywhere retain strict observance of the grid system in producing copy that users find both pleasing to the eye and in line with what they would expect to see.

Regarding setting out elements, grids afford superb precision. We can see this principle most prominently in maps, noting how locations are pinpointed with grid lines that represent coordinates. The pursuit of accurate cartography would enable navigators to discover new places in the great unknown parts of the world. Now, with the grid lines that mark both longitude and latitude, GPS devices allow us to get wherever we wish to go.

However, cartographer’s maps represent fixed “designs” that change only imperceptibly over many years. Cartography might be a science, but grids, with their mathematical precision, are brilliant and much-needed tools of artists, too. Throughout history, artists have been making use of grid lines to plan and paint images of their own, which capture the best, most pleasing proportions.

Easy to create and practically free of charge, grids also give us web and app designers the ability to lay out our work in an organized and precise manner. By enabling us to insert elements in boxes created by their intersecting lines, grids enable us to make a consistent user experience across multiple devices. For example, the dimensions and layouts of our computer and smartphone screens differ. Planning our work so that it can adjust to appear on different platforms keeps our designs intact, in proportion and in the places where our user expects to find them.

Designers use columns and rows, shaped according to set column width and row height proportions (such as 3:2 or 4:3), and gutters (the spaces between these “boxes”) to present elements of our designs in the best way.

Although we have the luxury of very high screen resolutions that allow us to show ever-more impressive and realistic designs, by using a grid based on a width of 960 pixels, we can make sure that our designs will translate properly to be displayed on many computer screens and mobile devices such as cell phones. However, we have a wealth of resources at our disposal to help us fine-tune our choice of grid system to match the design we want.

However you use the grid system to build your design, you should keep in mind other principles, such as the Golden Ratio. Aiming to create a consistent user experience also involves creating a pleasing user experience that will be consistent across many devices. If you keep in mind that your choices will be working in concert with the known tendencies of the user’s eye, you will be able to create eye-catching designs that are better organized, as seen by your users on computer, tablet, or cell phone screens.

 

Source: www.interaction-design.org

Author: Mads Soegaard

Posted in Knowledge sharing | Leave a comment

5 TRENDS OF VOICE UI DESIGN

At its core, the concept of interaction was always about communication. Human-Computer Interaction has never been about graphical user interfaces, which is why Voice User Interfaces (VUIs) are the future of user interface design.

An interface is just a medium people use to interact with a system—whether it’s a GUI, VUI or something else. So Why is VUI So Important? Two reasons:

Firstly, conversational interfaces are so fascinating because conversation is a form of communication everyone understands.

  1. It’s a natural means of interaction. People associate voice communication with other people rather than with technology.
  2. Users don’t need to learn to interpret any symbology or new terminology (the language of GUI), they can use English (or any other native language) to operate with a system. It doesn’t mean that users don’t have to learn how to use a system but the learning curve be reduced significantly.

Secondly, user expectations are changing. According to Statista, 39% of millennials use voice search. This audience is ready to be the early adopters of VUI systems.

Top 5 VUI Trends

When it comes to designing VUI, voice interaction represents the biggest UX challenge for designers since the birth of the original iPhone. But the great news is that the most fundamental principles of UI design that we use when creating products with GUI are still applicable to VUI design. Below you can find a few trends that will shape VUI design in next decades.

1. VUI THAT BUILDS TRUST

Trust helps to build a bridge between a person and a machine. If trust is absent, users will be unlikely to interact with a particular voice user interface.

The importance of the valid outcome (VUI should give the person understanding that s/he will receive exactly what s/he requested). It’s possible to achieve this goal by focusing on the following things:

  • Improving the accuracy of speech recognition (more sophisticated NLP algorithms).
  • Focusing on understanding the user’s intent (a reason for interacting in the first place). When users interact with a system, they have a particular problem they want to solve, and the goal of the designer is to understand what this problem is.
  • Providing meaningful error messages.
  • Crafting contextually driven flows. While it’s impossible to predict all commands that users might ask the system, designers need to at least design a user flow that is contextually driven. The system should anticipate users’ intent at each point of a conversation and provide users with information on what they can do next. For example, finding a restaurant near the user. When users search for a restaurant, the system should match exactly what the user is looking for.

The importance of user control (one of the 10 Usability Heuristics for User Interface Designby Jakob Nielsen is still applicable to VUI design).

  • The system should consider the natural limitations of a human brain (short-term memory limitations). The information provided by the system should be overwhelming. When people hear the system response, most users remember only the last phrase. Thus, it’s better to stay away from long phrases or providing a dozen different options while the user can remember just a couple of them at one time.
  • The system should react to a user request with appropriate feedback. This feedback should give users a full understanding of what the system is doing right now. For example, visual feedback lets the user know that the system is ready and listening; or in POD (Process of Doing). When a user sends a request to the system, the system shows a POD. POD isn’t a loading animation, it doesn’t just state the fact that users have to wait while a system is doing something, it provides valuable information of what the system does. For example, a POD for a command on pulling out a file from Dropbox might look like as someone search for a right file in storage.

2. ADAPTIVE USER INTERFACE

An adaptive user interface (also known as AUI) is a user interface (UI) which adapts to the needs of the user or context. VUI of the future will adapt for users — the system will analyze all information it has about users (including the information about current mental state and health condition) and their current context to provide more relevant responses to user requests.

For example, if a user has a high blood pressure at the current moment and decides to set a meeting in 2 hours, a digital assistant might suggest avoiding that, or suggest lowering blood pressure with exercise before the meeting starts.

3. VUI THAT CONVEYS PERSONALITY

Visual designers have a lot of options to introduce the personality in graphical user interfaces – fonts, color, illustration, motion, just to name a few. But what about VUI? Designers can convey personality using language itself — by playing with words, voice, and tone. Speaking of voice, a voice is part of the persona and it shapes its identity. Once we’ve associated a voice with something, it becomes part of its identity. And we experience emotions when we interact with such an interface, just like we when we interact with real people. People want human-understandable voices — not a voice that sounds human, but a voice that speaks coherently human!

Bad example: Siri voice by Susan Bennett – the voice that sounds almost human but people still know that it’s a machine. You can’t really have a dialogue with Siri. While you can ask Siri something like, “What is the weather like today?” You can’t ask more sophisticated questions such as, “What should I wear today?” As a result, you don’t have deep feelings for Siri, you know it’s just a robot.

Good example: Samantha voice from the film Her — the voice that sounds coherently human and people can be in love with it.

4. FROM NARROW AI TOWARDS GENERAL INTELLIGENCE

Human-computer interactions are shifting to conversation, but users expect more. Most of AI systems available today are still limited to Narrow AI — such systems use Machine Learning to solve a clearly defined (and, in most cases, way too narrow) problem. Narrow AIs have zero knowledge outside of their training data. It means that when a user wants to solve a slightly different problem, or the problem itself evolves, the system won’t be able to solve it and it’ll respond with something like, “I don’t understand.” So that you, as a user, face a wall.

In comparison to Narrow AI, General Intelligence is not limited to narrow domains. The concept of learning is at the foundation of GI systems — the fundamental difference between Narrow AI and General AI is that the General Intelligence systems learn without being expressly programmed (machines learn by themselves). GI system uses two types of learning — reinforcement learning (when a system uses all available information to solve a particular user problem) and supervised learning (when a system needs user assistance to solve a problem for the first time). Another difference is that a General AI system can learn to utilize other AI for general and specific purposes. As a result, different Machine Learning models can be trained dependently and work cooperatively. An advanced NLP GI system is able to learn from the first attempt by combining and processing information from multiple different data sources.

5. IMPACT ON SOCIETY

Widespread acceptance of VUI systems. Improving the quality of VUI AI-based systems will lead to better user engagement. The relationships between human and computer will be interactive and collaborative — people and computers will work together. This will impact society — just imagine that in ten years, you’ll walk into the house and just talk and control all kinds of machines.

This future will be with omnipresent AI: As users, we’ll trust AI even with the most important decisions such as “What school should I choose for my children?” VUI will improve the quality of life of older people and people with disabilities.

Conclusion

“The best interface is no interface“ is a famous quote of Golden Krishna, the author of the book The Best Interface Is No Interface. He and many other designers believe that people don’t want more time with screens, in fact they want less. Thus, technology should stop celebrating screen-based solutions. And it’ll happen relatively soon — the interactions of the future won’t be made of buttons.

With the rise of computer processing power, we’ll have more systems that will be able to calculate up to 1000 steps in 1 second. A user and a machine will work together, enabling General Intelligence.

 

Source: www.webdesignerdepot.com

Author: Gleb Kuznetsov

Posted in Knowledge sharing | Tagged | Leave a comment

UX Design For FinTech: 4 Things To Remember

Should you happen to ask your average UX designer to rank their favourite kinds of projects to work on, ‘digital financial services platform’ would probably not land in the top five. Perhaps, not even the top twenty, or even the top fifty.

Most designers do not get particularly excited about studying federal banking regulations or accounting for the complex bureaucracy that often accompanies fintech platforms. When you take a group of creatives and force them to learn about the minutiae of compliance standards or the intricacies of tax audits, you start to see their eyes glaze over.

Not only fintech is unglamorous, but it can also be challenging to design for. Project requirements are often meticulously detailed and riddled with industry jargon, and designers must strike a precarious balance between effortless usability and ensuring an errant tap does not leave the user in financial ruin.

So while designing for fintech may seem impossible or uninspiring, remember to think of it as a challenge, not an obstacle, and try to keep these four other tips in mind as well.

1. Factor In The Future

While generally good practice for any platform you are creating, factoring in the future is imperative when designing for fintech, primarily because the industry is in a near-constant state of flux.

We are in the midst of a digital revolution in the banking and investment sectors as they attempt to catch up to other, much more rapidly modernising spaces. Banks, credit unions, and financial institutions experience fast, and sometimes volatile change as their relationships to one another are reshaped by new technology.

What does this mean for your design? At a high-level, it means leaving ample room for future changes. A recent example: when the US government restructured its NAFTA deal, new tariffs were placed on specific items shipped between the U.S. Canada. This had significant complications for a project I had been working on. We needed new logic for tariffed items and even had to tweak the design to better explain and display the added cost to the buyer.

Granted, this was an eCommerce example – not precisely fintech. However, the principle is the same, and financial regulatory laws can get much more complicated than a simple tariff. Remember to stay up to date on the regulations relevant to the experience you are designing, and consider factoring in potential future changes as well.

2. Remember The Power Of Friction

Earlier this year, as part of Codal’s UX Case Study series with Usability Geek, I analysed the interface and user experience of the robo-investor Acorns, a popular fintech app. There is a lot to like about Acorns from a usability perspective, but one of their savvier design choices was intentionally making some of their processes harder to complete.

Increasing user friction for specific tasks is a pillar of fintech UX design. The inherent appeal of fintech is the ease of use, but it cannot be so effortless that it is easy for users to make mistakes with their money. We saw this in the Venmo case study as well. The payment app adds an extra step to sending money by forcing the user to confirm their action.

Design roadblocks like these help curb user mistakes and prevent disastrous errors. It impedes your users momentarily, but not their overall experience. Your users will thank you for making things a bit harder as they want to know their money is in safe, trustworthy hands.

3. Feedback, Feedback, Feedback

Another tenet of usability, providing responsive feedback to the user is crucial in nearly every permutation of UX design. However, for fintech, it is not just prudent – it is absolutely necessary, and for the same reasons, friction is so imperative in fintech design as well.

Users, especially ones who are not digital natives, are going to be much more reluctant to entrust an app with control over their finances. When interfacing with any financial services platform, whether it be banking, investing, budgeting, or anything in between, the user is going to require near constant reassurance and validation that their information is safe and that the tasks they are completing are in fact, achieved.

4. Facing FinTech

Designing digital experiences for the financial sector can be frustrating, and not always exciting, but it does offer a fantastic opportunity for designers to tackle challenging, real-world, and relevant UX problems.

When I asked the user experience designers at Codal, the UX design agency I work for, about the projects they learned the most working on, nearly all of them mentioned the web app we built for an enterprise financial services company just last year. The project featured everything we talked about in this article: complicated logic, tons of red tape, and a highly technical workflow that required some serious studying of financial workings.

However, in the end, our designers pulled off an engaging, user-friendly platform, and learned a lot in the process. So for your fourth and final thing to remember when designing fintech: do not forget it is making you a smarter, better designer.

Source: usabilitygeek.com

Author: Sean McGowan

Posted in Knowledge sharing | Tagged , , | Leave a comment

UX Debt: How to Identify, Prioritize, and Resolve

Continually prioritizing fast and easy solutions may help us hit release dates in the short term, but over time, repeatedly choosing shortcuts will leave us with mounting experience issues that adversely impact our users. These issues are known as UX debt and, if left unaddressed for too long, lead to costly, time-consuming problems that take effort to fix later on. Agile teams are particularly prone to UX debt as a result of heightened pressure to regularly ship new features and functionality. However, UX debt can accumulate in any project, regardless of the development methodology employed, and too much of it will result in a loss of trust, traffic, and revenue. In this article, we define UX debt and show how it can be identified; we also discuss methods for how to prioritize UX-debt issues and resolve them. While these methods are framed for Agile environments, they can easily be adapted to other development processes.

What Is UX Debt?

UX debt is similar to its technical counterpart, known as technical (or tech) debt. Originally devised by Ward Cunningham in 1992, tech debt refers to the additional time and effort costs that result from launching faster or easier technical solutions, instead of releasing the best approach. It implies that the cost of having to go back and fix problems after launch is always higher than launching ideal solutions in the first place (i.e., the debt is repaid with usurious interest). Like tech debt, UX debt is often incurred when designers and researchers are working under tight timelines or impractical project constraints. Other factors that contribute to UX debt include:

  • Skipping user testing
  • Disregarding brand standards and style guides
  • Design by committee
  • Misinterpreting the product vision
  • Acquiring or merging with other products
  • Poor communication or documentation
  • Insufficient QA testing
  • Legacy code or delayed refactoring

Why is it more expensive to fix a UX problem later, rather than before launch? For many reasons. First, redesigning and recoding consumes many resources: the team has to refamiliarize with the nuances and details of the already launched features, spend time debugging them, and then possibly retrofit other parts of the software. From a pure software-engineering perspective, coding the UI right the first time is much easier on the developers than having to change shipped code. But there are also user-experience reasons for the extra cost of UX debt:

  • Launching a suboptimal design impacts long-term market share, because many customers will give you one try and then give up when the design is too difficult or doesn’t satisfy their needs. Even if you fix their complaint later, the users won’t know, because they won’t resample your site or product once they’ve had a bad experience.
  • Users will become accustomed to the bad design. Then, after you change the design, people will be forced to change their habits and hate you for that.
  • Changing the design back and forth for any particular component of the overall UX will degrade the feelings of consistency and coherency.
  • Your failures will live forever on the internet. Since learning is social, users will continue to be “informed” for years of your missteps by blogs, message boards, video channels, and other sources that discuss the old version. Not only will this outdated information be harmful rather than helpful to your users, it will also scare away new prospects who come across descriptions of the bad design and any awkward workarounds people had discovered and posted.

Any UX debt will incur some of these costs. But the longer the UX debt remains unpaid, the more these costs will mount (think of “compound interest” as an analogy).

An example of UX debt can be seen on FedEx’s website in a carousel that appears on the product page for printed posters. Initially, the carousel displays four related products; however, clicking on the right arrow to view more related products reveals only one additional item. Rather than filling the content area with more images and links to related products, the carousel shows empty white space. A user looking for invitations or similar printed materials may grow frustrated at the lack of relevant products in this carousel. FedEx should add more related products to the carousel or update the functionality to accommodate varying amounts of content. As time goes by, teams easily forget about these seemingly small issues and the likelihood of going back to fix them diminishes when there’s pressure to move on to other priorities. However, these issues do impact users and should be addressed to preserve the website’s integrity.

Though the word debt is daunting for most people, the metaphor does not imply that UX debt should be avoided at all costs. Especially when working in Agile, there will be cases when speed to market and pressure to meet release dates necessitate time-saving alternatives. While certain types of UX debt (such as problems with integration, inconsistencies, and trouble preserving a simple conceptual model that explains and unites the entire user experience) are more likely in Agile, any decisions that will deliberately result in UX debt should be made carefully and collectively. Consider if getting to market faster is worth the risk of negatively affecting user perceptions and the high costs of fixing issues later on. When the answer is yes, the resulting UX debt should be tracked, managed, and, paid back gradually over time so that users don’t notice it and abandon the website or application entirely.

Identifying UX Debt

UX debt includes any ongoing problems in the experience due to launching a fast, easy, or careless solution that negatively impacts users. Whether it is introduced deliberately or accidentally, it’s important to look for UX debt in these areas of the experience that are prone to debt buildup:

For example, a press release on Symantec’s investor-relations website contains body copy that is too low contrast to be considered accessible. Though low contrast is not a bug, it is an example of UX debt that could negatively impact low-vision or color-blind users. Per the WCAG guidelines, contrast ratios between text and background colors should be 4.5 to 1 for normal-size text. The contrast ratio between the text color and background color on this page is only 3.2 to 1 and therefore, too low to be considered accessible. Symantec should have selected a body-copy color that meets accessibility standards and must now remember to go back and fix this issue of UX debt.

The best way to uncover UX debt is by getting real user feedback often and in a variety of ways. Though you should always conduct user testing before releasing sprint features, ongoing testing should also happen at least once a month and focus on the key flows and realistic tasks that users frequently do on your website or application. This approach will help you understand the overall health of the user experience and identify the most serious issues. Other user-feedback methodologies that can help you find UX debt include:

In addition to user feedback, set up recurring time with the entire product team, including developers, to review the overall health of the site or app. Open up the discussion for the rest of the team to bring forward any UX- or tech-debt items that may negatively impact the user experience. Product management can also bring up debt-related issues found by leadership or other stakeholders. If possible, share trends or patterns from analytics during the discussion so the team can decide together if further investigation is needed to identify debt.

Inconsistencies in the UI can be considered UX debt, but not always. It’s possible to have occasional slight discrepancies in the user interface that fit within the brand guidelines and don’t cause problems for users. For example, during an A/B test, there may be some temporary UX issues until the team understands which variation is optimal and whether it should be added to a design system. These types of inconsistencies should not be considered UX debt since the variations are temporary and intentional. (To avoid creating UX debt as a byproduct of an A/B test, teams should ensure that the winning elements are scaled into the design system with full consistency and clear standards for the new patterns or components.)

An example of an informational inconsistency in the UI that does count as UX debt was observed on Amazon. The shipping-for-returns page displayed inconsistent quantities for return items: the user wanted to return 4 pairs of pants, but the text on the page read Returning 2 items and the summary info said Refund subtotal for 3 items. This contradictory information caused the user to question the refund amount and to navigate back to the previous page to double check that the total estimated refund was correct. Amazon’s inconsistency is UX debt and should be addressed to help users move smoothly through the return process.

When actual UX-debt issues and bugs like these are found, their severity, frequency, and location in the users’ journey should drive the issue valuation and prioritization. Though in the following sections we discuss how to track, prioritize, and resolve issues when working in the Agile development process, the approaches and concepts outlined can be adapted and applied to any development methodologyand will help you track, rank, and gradually clean up UX debt over time.

Tracking and Prioritizing Issues

Once UX debt items are identified, there are a few ways you can track them for prioritization. Each method has pros and cons, so it is important to choose one that works best for your team and organization. Common ways in which UX debt items are tracked include:

  • Adding UX-debt items directly to the backlog for prioritization
  • Capturing UX-debt items in a spreadsheet, then adding them to the backlog

Adding UX-Debt Items Directly to the Backlog

Putting UX debt items directly into the backlog can work well for teams that have well-organized backlogs with clear severity indicators and prioritization processes. However, for large, complex organizations that deal with many user stories and product-backlog items, adding UX debt directly to the backlog could mean those items get lost or continually deprioritized in favor of new features and functionality. One user-experience professional who favors this approach said:

“We track our UX-debt items using an epic in our backlog. During backlog grooming, we review the list of technical and UX-debt items, then we collectively prioritize and decide what to tackle in the next two weeks. We do this before we plan for any new features and functionality so we can balance cleanup with new features.”

To make sure that UX debt gets the attention it deserves each sprint, create a product-backlog item or a label for UX debt and use the same severity indicators as for other items in the backlog. In this way, all items can be evaluated using the same dimensions for prioritization during grooming and planning.This method will also help teams look back and see how much UX debt was been paid back within a time period.

What will improve the product experience the most: a new feature or making an existing feature usable? Quite often, the latter choice is best, since a feature that people can’t use might as well not exist. Thus, fixing something that doesn’t work for users has the same effect as adding a new feature, in terms of what customers actually get to use. Therefore, UX problems with existing features could and should often get assigned higher priority than new features. Moreover, features are usually implemented in order of expected benefit, so that an old feature is likely to be intrinsically more valuable than a new feature, if only the old feature could be made to work for users.

Organize and Prioritize in a Spreadsheet

For teams with many UX debt items or complex backlogs, prioritize issues in a spreadsheet before adding them to the backlog. This method will protect the team from getting overwhelmed or ignoring long lists of product-backlog items. It will also help the product owner prioritize issues accordingly and add to the backlog only those UX-debt items that make the most sense for the product vision, users, and team workload. The following factors will reveal the biggest pain points in the users’ experience and should be included in the spreadsheet:

  • Description of the issue from users’ standpoint (how is it affecting them?)
  • Where in the experience it occurs (awareness, consideration, conversion)
  • Frequency of occurrence (how often does it happen?)
  • Who reported the issue? (user, team, stakeholder)
  • Level of UX and development effort needed to fix the issue (low, medium, or high)

Score each issue by assigning a value to the experience area, frequency, reporter, and level of effort to fix the issue. Then, use a prioritization matrix in the form of a scatter plot to see where the issues fall on the dimensions of user value and effort to fix. This visualization can help you rank issues and communicate progress in cleaning up UX debt back to stakeholders and leadership over time.

Though the costs associated with going back and fixing issues will always be higher than launching with the ideal solution in the first place, it is still important to weigh all of these factors when prioritizing to avoid wasting even more time, effort, and resources when cleaning up UX debt. One user-experience professional who favors this approach said:

“We added our UX debt to the backlog, but it got lost and overlooked amidst all of the other competing priorities. By organizing items in a spreadsheet first, the product owner, lead developer, and user-experience designer can review them together and determine a few items to add to the backlog for the coming sprints. It feels more manageable to pay back our UX and tech debt over time.”

The most important consideration to keep in mind is that UX debt and technical debt should never be disregarded altogether. Many Agile organizations tend to prioritize tech debt over UX debt, but focusing on one type of debt over another will only lead to more problems for users and more expensive fixes in the end. It’s also important to realize that the two types of debt often go hand in hand. Don’t completely abandon UX debt in favor of addressing tech debt, or vice versa. Prioritize efforts that aim to reduce tech and UX debt at the same time. It’s more efficient and ensures you won’t dig yourself further into debt by focusing on one type while abandoning the other. This approach will also help the product maintain full trust and credibility with users.

While the high-priority UX problems should definitely be fixed first, the lower-priority ones should not be abandoned completely. As the years go by, cumulated layers of barnacles will slow even the mightiest ship, and the user experience will feel like a lower and lower quality product, as users encounter small annoyances every step of their way.

Resolving UX Debt

Paying down UX debt can feel daunting at first and will take time, but there are a few ways to resolve it while still making overall improvements to your digital products. One approach is to dedicate a specific number of story points to fix UX debt during each sprint or every other sprint. The number of story points can fluctuate over time depending on the team’s workload, but try to address at least one or two UX-debt items per sprint, preferably more if bandwidth allows. Use easy-to-understand visualizations, evidence from user testing, and clear explanations of what was accomplished in each sprint to help leadership and executives understand the progress made and why it’s important.

Another approach is to plan a quarterly sprint dedicated to cleaning up tech debt and UX debt. The team should collectively decide what areas to focus on in the cleanup sprint and, at the end, show what was cleaned up. If an entire sprint isn’t feasible, some teams will take a day (sometimes referred to as a cheese day) rather than a full sprint to address as much UX debt as possible. Approaching resolution in this manner gets stakeholders and leadership on board with addressing debt items frequently, especially when progress can be demonstrated and communicated in terms of user and business value generated.

Conclusion

UX debt isn’t always avoidable but teams can organize and collaborate around how to address it. Include all of the right people as early as possible to discuss the risks of a premature or haphazard launch and develop a cadence in looking for less-than-optimal experience elements. Conduct regular user testing and heuristic reviews of the experience to ensure new UX-debt issues are found and prioritized. Leverage data, such as the scores used in severity plotting, to make the case for why certain issues warrant resolution over others, and show progress in debt-cleanup efforts. Acknowledging and formulating a plan for paying UX debt back over time will help you resolve it, before your users start to notice.

Source: www.nngroup.com

Author: Anna Kaley

Posted in Knowledge sharing | Tagged | Leave a comment

Keynote vs PowerPoint: Which Presentation App to Choose?

Keynote

When it comes to making the choice of Keynote vs. PowerPoint for presentation software, understanding where each tool works best is key. Keynote is presentation software designed for Apple devices, so it will only work on computers, tablets, and phones running iOS software.

Keynote allows users to create presentations that look sleek without a lot of design capability. The tools are easy and intuitive. The slide navigator includes options for designing slides with different layouts, animations, fonts and you can even bring in presentations from other software.

Pros of Keynote

 

Most of the functionality in Keynote vs. PowerPoint is similar, it’s in some of the slide creation details that the software really differs. Pros of Keynote include:

  • So user-friendly that someone who hasn’t built slides before can use it.
  • Plenty of high-design theme options to choose from.
  • Basic setup helps you align and position elements for a sleek overall design.
  • Made for different types of multimedia such as images, sounds, video and other file types. (This is a huge feature!)
  • Great integration across devices – go from your desktop to phone to tablet and keep working on the same presentation.
  • Animation, transition and transparency effects are polished and don’t have that silly look and feel often associated with presentations.
  • Software is free on all iOS devices.
  • Photo manipulation tools – i.e. cropping – is actually easy in Keynote.
  • There are plenty of extra templates that you can download and add if you don’t like one of the included designs.
  • The design looks less like a standard slide deck, with a more polished overall aesthetic.

Cons of Keynote

While Keynote is a powerful tool, the biggest problem is that it is only for Mac and iOS devices.

  • Not as highly adopted as other programs.
  • Does not support some 3D effects and shadows from PowerPoint; so beware if you bring slides over.
  • There is a learning curve if you are coming from other software.

Choose Keynote If:

If you are a Mac user and want to create presentations that don’t “look like PowerPoints,” then Keynote is for you. It’s relatively easy to use, comes installed with your OS (so there’s no software to buy) and provides a viable option for creating great presentations.

PowerPoint

PowerPoint is probably the most well-known presentation software. When it comes to comparing PowerPoint vs. Keynote, one of the biggest considerations is ease of use. If you’ve been using PowerPoint for a long time and are already comfortable with it, chances are that a switch might not be for you.

While this software was originally designed for PC as part of the Microsoft Office Suite (now called 365), it works on PC or Apple devices. Whereas Keynote works well on mobile devices, many functions of PowerPoint are more limited when creating presentations away from your desktop.

Pros of PowerPoint

PowerPoint is a powerful piece of presentation software and many people don’t even use it to the full potential. (This might actually be a pro or con, depending on your experience with the software.)

  • Most people have used PowerPoint of another Microsoft product and understand basic usage.
  • There are thousands of themes and templates to choose from, as default options and as add-ons.
  • Editing is easy and the interface and slides work using drag and drop.
  • Other Microsoft elements from Word and Excel integrate seamlessly so you can add documents or spreadsheets to slides.
  • Notes function converts slides to handouts that look and work great.
  • Data and chart integration for building quick graphics works exceptionally well.
  • Advanced functions provide a lot of control for experience PowerPoint users that can control almost any aspect of the design.
  • Smart design suggestions can help you create more visually appealing slides if you aren’t working from a rigid template.

Cons of PowerPoint

Because PowerPoint is so complicated, it can be problematic for some users. Cons include:

  • Adding multimedia is flaky and doesn’t always work if you present on a device other than where you built the slideshow.
  • Cropping and photo editing can be quite tedious.
  • PowerPoint makes it too easy to create a bad design with garish animations and effects that deploy with just a click.
  • You have to buy the software.
  • There are a lot of features that most users don’t use; they can get in the way.

Choose PowerPoint If:

PowerPoint is generally the best option in a team environment where people collaborating on slide decks are used to PowerPoint. It’s also the go-to option in a non-Mac environment. It’s highly compatible since slides will work on any type of computer and most people have some familiarity with using the software.

PowerPoint is also preferred for users that are bringing complex data or charts into slides, because it integrates with Excel, making this functionality a lot easier.

Conclusion

If you are working on a team that does presentations frequently and are in a Mac and PC environment, it’s probably a good idea to at least get comfortable with both pieces of presentation software. When it comes down to Keynote vs. PowerPoint, you don’t always get an option as to what type of software will be used.

When you do get an option, many Mac users working in slides without massive amounts of data seem to prefer Keynote. For PC users or anyone working with charts and numbers, PowerPoint is the go-to option for creating presentations.

Source: designshack.net

Author: Carrie Cousins

Posted in Knowledge sharing | Tagged , | Leave a comment

As a designer, success based on designing detailed mocks

I recently talked to my friend and mentor about a problem I previously had about misalignment on requirements which you can read the whole story here. Essentially the problem was that I had been going back and forth on making changes to my designs because there had been miscommunication on what we needed to have in the product before launching it. I have solved the issue by explaining this situation to my teammates and consolidating meetings, but when I explained the situation to my mentor, a question he asked me was:

What does success mean to you?

I had an idea about what success meant at the moment, so I said, albeit seemingly unsure as I started with lots of “I think” statements (note to self: you know what you are doing), was success means finishing mocks and getting feedback that I was going in the right direction. My mentor explained that this kind of success isn’t the kind of success designers should be thinking about. The kind of success we need to be thinking about is how it can support business and user objectives and it’s something which can be measured.

Success could mean something like time on task and adoption. For my product, success could mean integration and efficiency. Integration from the business perspective of gaining more partners, user perspective of streamlining existing processes of doing a task. For efficiency, from the business perspective, this can mean gaining more users based on ease of use and from the user perspective, this means less friction and less time to achieve tasks. As you can see, the way a designer views success should align with what the team believes to be success, which is based on metrics and impact of how it is perceived and used by the world, not just delivering pretty design artifacts.

Based on what I learned, defining success is crucial to the success of a product and how a team works.

Teams need to be aligned on success or there is else lots of churn or no thinking around meeting core objectives.

A team needs success metrics or else metrics affect your day to day work. Without metrics, there is lots of churn and not thinking about meeting core objectives. Also without a core objective, the small tasks wouldn’t matter because the metrics that would achieve a core objective wouldn’t be existent.

There are two types of metrics to determine success: short term and long term metrics, and a vision statement to ensure everyone is on the same page with what success means as a team.

Vision Statement: The core goal of your product and how it helps users accomplish their goals (Creating new ways to enable communication for everyone)

Short-Term Metric: Make very clear towards vision (efficiency during onboarding, completion of task).

Long-Term Metric: What could this directly affect? (i.e. Development tools from (name of product) will help 20% of partners onboard and create (outcome) in the beginning 2019 (aka adoption), Serve NBU customers in three countries on x).

If we are talking about short term and long term metrics in the form of OKRs, short term metrics are typically a P0 or P1 task. long term metrics are most likely not achievable in one quarter so they are P3 or P4 tasks. P meaning priority and the numerical value representing importance and what is achievable now.

Design is supposed to support an objective based on customer and business goals.

It can be so easy to get wrapped around the concept of shipping features in a big company that you forget to think about what a design is supposed to achieve.

Objectives (success metrics) and outcomes > Features

This is something that had been happening to me. My mind had been so preoccupied with requirements and doing something because it was a requirement, that I hadn’t thought about how it contributed to the user experience of the product and how it aligned with the existing success metrics of the product. It doesn’t matter about the amount or power of features you add to a product. If they don’t contribute to helping the user meet their goals, it’s essentially useless.

Ask questions around how a process can help us get to our outcome

Success isn’t designing mocks, it’s about designing solutions that meet the needs of our users and satisfy the business’s bottom line. Designers can enable the process that allows others to understand what those things are and use mocks as a way to visually convey objectives.

When having meetings, we have the ability to guide these conversations toward user objectives and understand the kind of metrics we are using to gather data that would determine the product’s success. These conversations should be framed around what what does a button enable the user to do instead of where should we put the button or what color should this button be. It is our job to decide placement and visuals while the goal of a feature that achieves a success objective is something everyone needs to decide on.

Source: uxplanet.org

Author: Tiffany Eaton

Posted in Knowledge sharing | Leave a comment

What’s a Design Sprint and why is it important?

What is a Design Sprint?

A Design Sprint is a unique five day process for validating ideas and solving big challenges through prototyping and testing ideas with customers. The book “How To Solve Big Problems and Test New Ideas in Just Five Days” (by Jake Knapp) refers to it as:

“The ‘greatest hits’ of business strategy, innovation, behavioural science, and more — packaged into a step-by-step process that any team can use.”

In five days, the Design Sprint will help you to:

  1. Understand. Map out the problem and pick an important area to focus.
  2. Ideate. Sketch out competing solutions on paper.
  3. Decide. Make decisions and turn your ideas into a testable hypothesis.
  4. Prototype. Hack together a realistic prototype.
  5. Test. Get feedback from real live users.

What do you need to run a Design Sprint?

  • A decider. They call the shots. Whether that’s the CEO or senior executive, they should be involved in the discussions early on since their decision will influence the sprint goal and the final product.
  • Facilitator. The time keeper. They keep track of the team’s progress during the Design Sprint and ensure that everyone is playing their part. They need to remain unbiased in their opinion when it comes to decision time.
  • Marketing expert. The person who is skilled at crafting your company’s messaging to your customers.
  • Customer service. They interact with your customers on a regular basis and truly understand who your users are.
  • Design expert. They design the product and help to realise the vision of the goal.
  • Tech expert. They are in the best position to understand what your company can build and deliver.
  • Financial expert. They can explain how much the project will cost and how much the company can expect to get from it in return.

Preparation:

  • Block out the entire week in you and your team’s calendar.
  • No devices are allowed in the room. This is so that the entire team is focussed one hundred percent of the time.
  • Stock up on post-it notes. You’ll need these to jot down ideas and map them on a wall.
  • Whiteboards and plenty of markers.

Monday: Understand the problem

What is the long term goal?

“Why are we doing this project? Where do we want to be six months, a year or even five years from now?”

At the start of the sprint, you need to set a long term goal. This should serve as your beacon of light to keep everyone moving in the same direction. Once established, it’s important to turn the goal into actionable items by rephrasing your assumptions and obstacles into sprint questions.

For example, if your long term goal is to “build an army of loyalists through products that deliver reasons to return”; then a sprint question could be “will customers feel motivated to recommend us?”

What are your users’ pain points?

After you’ve defined your long term goal and sprint questions, start by mapping out your customer journey. It’s important to understand who your customers are, so conducting user research in advance is vital.

  • Empathy mapping. The Empathy map is a visual way to better understand your users and prioritise their needs. The map helps to identify any key themes and problems affecting your users based on their quotes, actions, behaviours, pains and feelings captured throughout the user research and expert interviews.
  • Customer Journey. The Customer Journey map helps to visualise a customer’s end to end experience with your product or service. This allows the team to narrow down a broad challenge to a specific target for the sprint.
  • Swim lane diagram. Combining the Empathy map with the Customer Journey map will create a Swim Lane diagram. This diagram serves to create a heat map of the problems that exist within each step of the customer journey.

How Might We turn this problem into an opportunity?

The How Might We method is used to turn existing problems into opportunities. For example, if the problem is that “users struggle to know what to buy for their friend as a gift”, then the How Might We could be “how might we help the user better understand what they know about their friend?”.

Use the dot voting system to prioritise the How Might We notes and decide on which focus area to target for your sprint.

Which problem do we target?

“Who is the most important customer, and what’s the critical moment of that customer’s experience?”

At the end of the day, the decider needs to select one target customer and one target event on the Customer Journey map to focus on. This will become the focus problem for the rest of the sprint.


Tuesday: Ideate the solutions

Remix and improve with Lightning Demos

Lightning demos encourage your team to research competitors and find examples of existing products that could serve as inspiration for your solution. Each person should give a 3 minute demo of their findings.

Sketch in four steps

The four-step sketch method forces you to create solutions in an effective manner whilst iterating on each variation along the way.

  1. Notes. Start with twenty minutes to take notes of the goal, opportunities and inspiration you’ve collected earlier on.
  2. Ideas. Spend another twenty minutes drawing out rough ideas to form your thoughts.
  3. Crazy 8s. Take your strongest solution and sketch out eight different variations of it in eight minutes, known as the ‘Crazy 8s’ exercise.
  4. Solution sketch. Draw a detailed end to end solution for the problem in the next thirty minutes or more.

Wednesday: Make a decision

Decide on the best solution to prototype

The process to reaching consensus on the best solution can be carried out in five steps:

  1. Art museum. Put all the sketches on a wall to create an art gallery. Ideally, the sketches should be anonymous, so the facilitator should assist with hanging them up.
  2. Heat map. Each team member is given three dot stickers to assign to the sketches or parts of the sketches that they find interesting. This is to be done in silence.
  3. Speed critique. Each member selects a drawing that is not their own and quickly walks through the solution, using sticky notes to capture the big ideas.
  4. Dot voting. Each team member is given one vote (one dot sticker) to choose the best solution and justify their decision.
  5. Supervote. The decider makes the final call with three votes (three dot stickers).

Create a story board

On a whiteboard, draw five to seven frames (and up to no more than fifteen) to start the storyboard. The first frame should contain the opening scene to provide context and familiarity to your users just before they interact with your product. For example, it could be a simple web search, a store shelf, app store or social media site.

Thursday: Create a prototype

Once you’ve drawn out the storyboard, devote the entire day to building the prototype. The secret to building a prototype is to fake it.

Aim to create a prototype of “Goldilocks quality”. Ideally the quality should be good enough so that it appears real to users but not too much that you spend forever perfecting it. For example, creating mockups using Sketch or Keynote and importing that into a prototyping tool like Invision is an easy way to get software prototypes out quickly.

To tackle the task, the sprint team should be split up into the following:

  • Makers. Usually at least 2 designers or engineers responsible for creating the individual components of the prototype.
  • Stitcher. Either a designer or engineer should be collecting the components from the Makers and combining them into a seamless fashion.
  • Writer. Usually the product manager should be writing realistic text to ensure that the language makes sense to the user.
  • Asset Collector. They are responsible for scouring the web and image libraries to provide photos, icons or relevant content to assist the Makers.
  • Interviewer. They should write the interview script for Friday’s customer interviews .

Friday: Test your prototype with users

Test it with users

When it comes to user testing, the Nielsen model suggests that you only need to interview five users who fit in with your target customer profile. The rationale behind this is that testing more than five users diminishes the value of return since you will already have identified 85% of the problems after listening to five people.

The questions and tasks that you ask the user to perform during the interview should simulate a real world environment whilst the sprint team watches the recording in a separate room.

Learning from feedback

Ideally, you should watch the recordings together as a group. Draw a table on a whiteboard divided up into five columns for the five customers and rows for each area or task of the prototype they addressed.

Look for patterns and themes in the feedback and work towards prioritising these into your backlog as items or features to address in the next iteration of your product.

Key takeaways

  • The user is king. The entire design sprint process is user-centred. It builds products and services based on a solid understanding of the user’s wants and needs and asks for feedback and validation directly from them towards the end of the sprint.
  • Considers all perspectives. Design Sprints gather all important people in one place. This means that there’s less of a bureaucracy and siloed structure in the organisation because the process facilitates cross-team collaboration.
  • It’s efficient and effective. A sprint cuts out all inefficiencies and ineffective discussions. No more dreadful back-to-back meetings that take up your entire day leaving you with little time to get anything done. A five day sprint forces you and your team to focus and work towards something realistic by the end of the week.
  • Manages your stakeholder expectations. There is clear visibility and alignment from everyone on Day 1. Getting your stakeholders’ buy-in early on and throughout the sprint discussions builds trust and respect between all parties.
  • Learn fast, fail fast. The sprint helps to obtain a clear vision of the goals upfront. It forces you to make critical decisions and solve complex problems fast. This means that you and your team can save months of design, engineering and development costs. The bonus? You’ll be able to get your product to market faster because you focussed on the right thing.

Final words

I found the Design Sprint masterclass to be a great introduction to the concept and methodology. In comparison to the book (which I would also recommend reading), it was a fun and interactive way to get practical experience in a classroom environment. I plan to use this process in my work going forward and hope to influence how other people in my organisation view and approach complex problems.

Source: uxplanet.org

Author: Gloria Lo

Posted in Knowledge sharing | Leave a comment

7 UX Deliverables: What will I be making as a UX designer?

What does a UX designer actually produce? Here, we will explore the concept of UX Deliverables, a term that describes the outputs of a UX design process during its various stages. The deliverables produced by UX designers vary according to their role in the design team and also depending on the methods and tools used by each role. We will provide an overview here of some of the most common types of deliverables.

A UX design process typically follows something similar to a design thinking approach, which consists of five basic phases:

  • Empathize with the users (learning about the audience)
  • Define the problem (identifying the users’ needs)
  • Ideate (generating ideas for design)
  • Prototype (turning ideas into concrete examples)
  • Test (evaluating the design)

The first two phases (empathizing and defining the problem) are often grouped into the term “User Research” – i.e., understanding both the nature of the users and how this affects their needs. A number of tools and methods can be used in each phase. Each tool or method might produce a different type of output (UX deliverable), but here we will focus on some of the most commonly used types to give you an overview of what you might be expected to produce in a UX design career.

User Research Deliverables

Personas

A persona is a fictional character which the designers build as a sort of user stereotype. It represents the typical users, their goals, motivations, frustrations and skills. Other information such as demographics and education backgrounds complete the persona. Depending on the scope of the projects, designers will generate a number of different personas to capture as wide a part of the audience as possible. Generating personas helps designers empathize with the users and demonstrate a thorough understanding of who they are and what they want to achieve.

Storyboards

A storyboard is an idea borrowed from the movie industry. It essentially consists of a comic strip, outlining the user’s actions and circumstances under which these are performed. The power of this idea is that it doesn’t only demonstrate what the user does, but it also reveals the environment, which might be affecting how or why the user does something.

Customer Journey Map

A customer journey map (also known as an experience map) is a diagram that represents the steps (i.e., the process) taken by a user to meet a specific goal. By laying the process out along a timeline, the designers can understand the changes in context as well as the motivations, problems and needs along the way. By identifying the major stumbling blocks for users, the designers can better relate to their problems and begin to see where a product or service might fit along the way to help the user.

Ideation Deliverables

Brainstorming

Brainstorming is a process whereby a team of designers generate ideas about how to address the issues and opportunities identified in the user research phase. The concept here hinges on the generation of as many ideas as possible (even if they are completely wild) so that the designers can later sift through these and reduce them to the ideas that seem most promising. A central point is that the team members are free to explore all angles and realms; indeed, the best solutions can sometimes sprout from the craziest-sounding notions.

User Flow

A user flow diagram is a simple chart outlining the steps that a user has to take with your product or service in order to meet a goal. In contrast to the customer journey map, the user flow diagram considers only what happens with your product (that is to say, ignoring all external factors). These diagrams can help designers quickly evaluate the efficiency of the process needed to achieve a user goal and can help pinpoint the “how” (i.e., execution) of the great ideas identified through brainstorming.

Prototyping Deliverables

Sitemaps

Sitemaps show the hierarchy and navigation structure of a website. Such maps are also often produced for mobile apps, as well. They serve to show how the content will be organized into “screens” or sections, and how the user may transition from one section of your service to another.

Low-fidelity prototypes

Once you have your sitemaps ready, you can begin to sketch how the content will be laid out on each screen. A low-fidelity prototype omits any visual design details and serves as a rough guide to allow designers to get a feel of how and where they should place content. Low-fidelity prototypes can start as hand-drawn sketches (which are great, because they are fast and cheap to produce, so you can easily throw them away if you change your mind) and later refined as computer-drawn wireframes, which are more faithful to the presentation of information on a real screen, but still lacking visual design details.

High-fidelity prototypes

These prototypes are a step up from low-fidelity prototypes. Often they are called pixel-perfect prototypes because they try to show all the visual and typographic design details of a product, as it would be shown on a real screen. They take into consideration physical screen dimensions and are produced in a size that corresponds to the physical device’s size. Although these require a lot more time to produce compared with low-fidelity prototypes, they are often the type of illustration that you would want to show to a customer or stakeholder.

Interactive prototypes

The low- and high-fidelity prototypes discussed above are little more than a collection of static images. To better evaluate your designs, you might turn these prototypes into an interactive demonstration, aimed at showcasing how the interaction might work with these. Commercial prototyping software allows you to define clickable areas, transitions and events, in order to produce an interactive prototype that captures the user flow process and demonstrates interactivity, without having to write a single line of code. In some cases, you can use a much simpler tool, such as PowerPoint or Keynote. Even better, you can use these interactive prototypes in early user tests, before any code has even been written. This way, you can make sure that your design is likely to work well, before committing to the expensive and laborious process of developing code.

 

Evaluation Deliverables

Usability report

Once you have a design that is implemented (even if only as an interactive prototype), you can begin to run some evaluations of this design with real users. Evaluation can take many shapes and forms. You can have some users try out your design and then interview them, or work with them in a focus group: This is an example of qualitative evaluation. You could bring users into a lab and ask them to accomplish specific tasks with your prototype, while you measure things such as the number of errors, number of clicks, or time taken to complete the task. In the lab, you can use special equipment, such as eye-tracking cameras, to see where your users’ attention is spent while navigating a particular design. You could also ask them to perform the same task using prototypes that offer alternative design implementations, so you can compare them and see which design is better (known as A/B testing).

There are many ways to evaluate a design. No matter what you end up doing for evaluation, you will have to summarize your findings into a usability report. A complete usability report typically contains the following sections:

  • Background summary: what you tested, where and when, the tools and equipment that you used and who was involved in the research
  • Methodology: how you went about the evaluation, what tasks you asked the users to perform, what data was collected, what scenarios were used, who the participants were and their demographics
  • Test results: an analysis of all the data collected, including illustrations such as bar charts and textual descriptions of the findings, and user comments that might be particularly illustrative or enlightening. Depending on whom you are communicating the report to, this section may contain some more technical details, such as the type of statistical analyses used.
  • Findings and Recommendations: what do you recommend, based on the data that you collected and your findings? Write down what worked well, what didn’t and why. State what should be done next to improve the design or move forward with the process.

Remember that a usability report might be directed towards a number of other roles in your project. Managers will probably just need an executive summary and a statement of how the findings impact the overall project timeline. Other designers will be more interested in how you carried out your evaluation and would like all the details. Developers are probably only interested in your findings and recommendations. Ensure that your report is structured and worded appropriately for its audience.

Analytics report

When a designed product has been released and has been running for a while, your company might make some usage analytics data available to you. Looking into this data may offer great insights into how to improve usability, particularly if this data contains users’ transitions and behaviors in your product.

For example, you might find that many users in an e-commerce website are not registering to complete a purchase. Does it mean that the registration process is not easy enough? Does it mean that they don’t see there is such an option? An analytics report contains the insights from this data and highlights areas where the design might be improved. While it is tempting to just put in the nice visuals and charts produced automatically by products such as Google Analytics, the UX designer’s job is not just to lay down the facts but also to interpret them. So, your report must contain the data, but also plausible explanations and recommendations on what to do. It’s also a useful record so that you can see the impact that design changes might have had on your website, after you have identified issues and attempted to address them.

The Take Away

In a 2015 article for the Norman Nielsen group, UX specialist Page Laubheimer analyzed the type of UX deliverable that UX designers most frequently reported as being asked to create as part of their role. Wireframes and prototypes were reported to be most commonly produced, followed by flowcharts, site maps, and usability/analytics reports.

These are what we consider to be “classic” UX deliverables, but one important point to keep in mind is that while these deliverables are produced and shared with others, many other types of deliverables will be produced but never shared (hence ranking lower in this study). In order to produce a wireframe, should a designer not have a complete understanding of the users and their needs? Often, management, clients and other team members are interested only in the type of deliverable that helps them advance their tasks, as well. Given this, the types of the deliverables you produce might need to be “tuned” to whom you are going to share them with, too.

In your role as a UX designer, you will invariably have to produce deliverables for each stage of the design thinking process. Whether you keep these to yourself or share them with others, you need to practice your skills in as wide an array of tools and methodologies as possible, and become familiar with all the types of UX deliverables out there.

Source: www.interaction-design.org

Author: Andreas Komninos

Posted in Knowledge sharing | Tagged | Leave a comment

15 Guiding Principles for UX Researchers

We’ve found that a lot of first time UX researchers have similar questions and concerns when they start working in UX design. So, we thought we’d round up and tackle some of the most common questions to form a set of useful principles for UX researchers. Of course, this isn’t a complete guide to UX research(there are some fairly weighty tomes out there which do that) but it’s a good starting place to answer some of those nagging UX questions.

Mix It Up

The best researchers don’t use a single tool to do their research. They take a host of different methods, tools, etc. and then mix them together. This gives you a much greater chance of finding the actual issues and then being able to fix them.

It’s Easier To Find “You Got it Wrong”

Research can quickly help us work out when we’ve got something wrong. If you add a new feature and your first five research participants hate it – there’s probably a problem. However, a hundred people can use something without comment and it may still not work.

You Can’t Standardize Sample Sizes For All Your Research

Sorry, but sample sizes need to be calculated based on the risks you’re willing to assume in any given piece of research and based on the type of research you’re carrying out. Don’t try and use a single size for all of your research – it’s a flawed approach.

Testing With Just One User is Not Pointless

Imagine you’re creating a new word-processing package and you sit down with your first user and they try to save a document and you see that the process is broken. How many more users do you need to test that with? None, right? Some problems are universal and it only takes one user to point them out.

Increase Sample Sizes for Better Accuracy

The bigger your sample size, the more likely your data is to be accurate. There’s a general rule of thumb that says to double the accuracy you have to increase the sample size by a factor of four!

Randomizing Can Overcome Research Design Flaws

If you can change the order of questions, responses, process flow, etc. then do it. The more random the path you take – the more likely it is that you’re going to get consistency and minimize experimental design flaws.

Research Results Belong to No-One

All that data you’re collecting? It’s not yours. It’s not your team’s. It’s the company’s. The more you get your user experience research out into the company as a whole – the more likely it is that your company will start focusing on user needs as a priority. Don’t create a UX silo in your business; let the data flow and reap the rewards.

Scale Ratings In Questions Aren’t That Important

Sure, there are plenty of arguments about whether an x-point scale is more accurate than a y-point scale and whether you should have a neutral rating or not. None of them are important enough to spend more than 5 minutes worrying over – pick a scale and do the research already.

Participants Need to Reflect Personas

Not everyone is a user or even likely user of your product. Not every user fits your target market. Get your user personas out and recruit to the persona – that way you have the most chance of getting results that actually work for your target users. You can’t please all the people all of the time and UX professionals shouldn’t even try to.

What They Say vs. What They Do

It’s often said that what people do is what matters and not what they say. We don’t agree. You need to measure both what people say and what they do. Then you can explore the reasons for the disconnection between the two positions. Sometimes people really do want what they say they want and sometimes they don’t. Knowing when those things are true matters to the user experience.

Keep Growing Your Toolkit

There are going to be new ideas and methods floating out there for a long time to come. Don’t dismiss them without trying them. Even if they suck, you’ll have learned that they suck rather than assuming it. In many cases even the worst tools can offer reasonable insights if they’re adapted properly.

Usability – A Polite Fiction?

It is impossible to measure usability. What we can measure is when something is not usable. Those measures are fluid – they change from product to product, user to user and UX researcher to UX researcher. That’s OK, finding problems is part of what research is about. We already know it’s much harder to show there is no problem than to find a problem.

Keep Reports Short

Sure, the method was amazing and innovative and the results were incredible but… you don’t need to write a book to get that across. If you want your research to have wide value in the organization keep your reports to a minimum. However, don’t let that stop you from creating more detailed work as a learning tool within your own environment or from writing that book if you intend to publish it commercially.

Be Aware that Observers Observe Differently

There’s a reason police treat eyewitness testimony with a certain healthy scepticism. People see what they’re going to see and rarely will witnesses see the same things. That’s not a major problem; in fact, it means that adding observers may increase the overall success of research – if you all identify different problems, that’s better for the users (as long as you intend to fix all those problems, of course).

And don’t forget that the act of observation may also change the results that you get.

Cults of Personality Suck

There are a ton of UX gurus out there. Some will be highly trendy today and treated with contempt tomorrow or vice-versa. There’s no one “right” way to be a UX researcher; ignore the name attached to UX ideas and focus on the underlying idea instead and treat everything with a healthy dose of scepticism and interest.

Source: www.interaction-design.org

 

Posted in Knowledge sharing | Tagged | Leave a comment

Paging, Scrolling, and Infinite Scroll

As I’ve noted many times before, people do notnecessarily read left to right—and certainly, not in anything that is reliably like an F-pattern. However, once people find your content, they do reliably read it from top to bottom.

Wrapping text to the next line, continuing line after line, and presenting lists of discrete items of information are the two safe, reliable ways of designing digital content, especially for small mobile devices.

But what about when your content goes on and on? While there’s great concern about the right way of displaying arbitrary amounts of information, people make a lot of design decisions on the basis of hearsay, opinion, fear, or inertia. Plus, they assess existing design patterns based on incomplete data or bad implementations.

People Scroll

The first corollary of people reading from top to bottom is that people scroll. Designers don’t need to worry about scroll-bar visibility or providing little animations that tell users to scroll. People already know they need to scroll, and they generally scroll to explore the content on any page you offer to them.

Of course, it is possible to inadvertently create a false bottom for a page, where the user interface makes it look like the page ends, discouraging the user from trying to scroll any further. But it’s not hard to avoid this problem, so it’s not something we typically encounter anymore.

More common is the opposite situation, where people wonder whether they have reached the end of a page. So always provide plenty of extra space beneath the end of the content to make this clear—and to encourage people to scroll the content to the middle of the screen where they can read it more easily.

When a Page Doesn’t Work

The earliest useful microcomputers mapped the display of content to the dimensions of the screen. The page size was the same as the size of the monitor’s viewport. If you needed to display more information than would fit on the screen, the user would have to issue a command to view the next page of content.

However, since at least the mid ’80s, computers have had windowing systems. So, by the time the Web came about, computers could already load arbitrary amounts of data into a page that is larger than the viewport, allowing users to just scroll, and this was the obvious way to build almost every digital system.

Designers could create a page that was full of all sorts of information and just assume that everyone would scroll down to see more. This has worked great. Today, most news articles and other content comprises just one page.

You can use clever design and code to sidestep issues with loading performance. For example, Amazon product-detail pages are very long, but users think they load quickly because what is visible at the top of the page loads immediately while the rest of the content on the page loads as it can—that is, employs a lazy loading design pattern.

Nevertheless, it is sometimes impractical to load all search results or other long lists of data on just one page. What should you do then? There are three design options in this case:

  1. Paging
  2. Automatic infinite scroll
  3. Manual infinite scroll

Paging

Paging simply means displaying and enabling users to navigate a series of pages that contain contiguous chunks of content. A specific number of items in a list, rows of a table, or lines of another type of content load on each page. A set of pagination controls appears on the page, usually right after the content itself, indicating the current page and enabling users to access other pages.

Pagination controls can vary almost infinitely. You can list the other pages, provide Previous and Next buttons, allow jumping to specific pages, and combine these elements in various ways. You can also duplicate these controls at the top of each content area to help orient the user, but this can sometimes be counterproductive. However, paging is all too often the default design choice—maybe because a lot of development practices are stuck in the past. However, just because this is the traditional design option that doesn’t make it safe, and in many cases, its problems outweigh its benefits.

Benefits of Paging

  • Paging may be the default approach. Paging is built into a lot of frameworks, so developers assume this behavior is optimal. Unless you want to argue with them, you’ll get lots of paging.
  • Paging limits user choice. This can be a good thing. Google, for one, uses paging to make people focus on the top few search results because they know almost all good results are there. You can reduce the paradox of choice simply by restricting easy access to options.
  • Marketing can easily measure clicks. Measuring scrolls is harder—though not impossible. Marketing is happy counting clicks. This is why some news sources make you click to read more. They can measure each click, thinking they’ll have a better engagement number to tell their bosses and investors.

Problems with Paging

  • Users still have to scroll. Unlike early computers, page boundaries never line up with the viewport, so the user has to scroll by some amount to read the content, then press a button to see more, and so on.
  • Pagination controls vary widely in their form and function.Therefore, every user must learn their position and modes of interaction for every new site and app.
  • Having too many controls can be confusing. They don’t give users more actual choices, but add complexity, so discourage users from interacting at all.
  • Users perceive page loading as slow and burdensome. This can discourage interaction with pagination controls. Having to click something further limits users’ desire to view anything beyond the first page of content.
  • Users may not notice the pagination controls. They might assume that the content that is currently visible is all that is available.
  • Page loading tends to be slow. This is especially true when loading entire pages from scratch rather than refreshing only the content area. If users typically display multiple pages, it is much less efficient to load entire pages.
  • Multiple selection, or batch selection, has insurmountable issues.Users cannot tell whether selection applies per page or for the whole list of results. I have worked on solving this problem for 20 years and nothing has helped much.

Automatic Infinite Scroll

Before bound books with pages existed, there were scrolls. The natural way to get more content is just to read more content. Remember, people scroll.

Infinite scroll pretends to display all the content in a single list on a single page, but it’s faking this. It actually breaks the content into little chunks. Really, automatic infinite scroll is just paging with the automatic display of the next page of content, whose content it adds to the current page.

To avoid users’ perceiving any delay, any infinite-scroll system should prefetch the next most likely content users would see when scrolling. The amount of content it loads and prefetches must be calculated based on both the type of content and the expected—or observed—user behavior. Optimized prefetching can actually involve less data transfer than a paging system.

There has been a lot of badmouthing of infinite scroll, but these negative perceptions are all based on bad implementations. Losing the position of an item the user tapped or clicked when the user returns to an infinite scroll list is a result of bad design and coding choices, not an issue that is intrinsic to this pattern.

Benefits of Automatic Infinite Scroll

  • It provides entirely natural browsing of content. The user need only scroll.
  • Batch selection is clear to users. All selections are from a single list.
  • It provides the best possible performance. This is especially important for displaying large amounts of information
  • Mobile apps can support alternative scrolling functions. These include indexed fast user scrolling.

Problems with Automatic Infinite Scroll

  • It can result in unnatural, frustrating behaviors. These occur if automatic infinite scroll is not implemented correctly.
  • Its proper function adds implementation complexity. Automatic infinite scroll requires significant coordination between the presentation-layer code, APIs or Web services, and data storage.
  • You must design entire page templates to support infinite scroll.Otherwise, an implementation can prevent users from accessing the bottom of a page, slow access to the top of the page, and cause users to become disoriented.
  • Scroll-bar size and position reflect only what content has loaded.Since the scroll-bar size and position don’t reflect the length of the entire list, users may become confused about where they are in a list.

Manual Infinite Scroll

One simple change to infinite scroll can make a lot of things easier and alleviate a lot of the concerns product teams and developers have about it: making it manual. Manual infinite scroll simply removes the automatic function, making the user click or tap a button or link to load the next chunk of data.

Although automatic infinite scroll usually works fine, it does take some effort to implement it correctly. Therefore, it has a bad reputation that is unfounded. Acknowledging this can help you persuade everyone on your project to get 90% of the way to a good design solution.

Because a button or link to load more content is so important to this function, you must design it well. The best solution on a mobile device seems to be for it to take up an entire row below the content or at the end of a list, clearly affording a tappable target.

For example, in a list view or table, this affordance might say something such as “Show next 20.” I prefer show instead of load or anything else because it’s a user-facing control. The system loads content so it can showthat content to the user. These subtle wording distinctions help more than you might think.

This function should communicate exactly how many more items or rows will load, but make sure this is not hard coded to ensure it always provides an accurate value, not just the typical page size.

Benefits of Manual Infinite Scroll

  • Scrolling through content provides quite a natural browsing experience. The user can scroll through all available content on the page.
  • Batch selection is clear to users. All selections are from a single list.
  • It is conceptually similar to paging. Therefore, manual infinite scroll is an easy sale to database and software-development engineers.

Problems with Manual Infinite Scroll

  • The user must press a button to load content. Thus, manual infinite scroll is more labor intensive than automatic infinite scroll.
  • It can result in unnatural, frustrating behaviors. These occur if manual infinite scroll is not implemented correctly.
  • Its proper function adds implementation complexity. Manual infinite scroll requires significant coordination between the presentation-layer code, APIs or Web services, and data storage.
  • You must design entire page templates to support infinite scroll.Otherwise, an implementation can prevent users from accessing the bottom of a page, slow access to the top of the page, and cause users to become disoriented.
  • It does not work well with indexed scrolling functions. Such alternative scrolling functions are not supported adequately.

Floating Controls

A valid concern for many long pages, especially those with infinite scroll, is the disappearance of key content or functionality. What if scrolling makes the use lose context because the header is outside the viewport? What if a user doesn’t notice a button way down at the bottom of the page so doesn’t submit a form?

The answer isn’t shorter pages, but a floating masthead and chyron. These floating elements have a fixed position in the viewport, and the page content visible in the middle of the screen moves beneath them.

The masthead is at the top of the screen. It need not be just the branding and app name, but can extend to include page titles, tabs, and other information that is important to maintain context.

The chyron is a footer for an app or site. However, it should never include the normal elements of a traditional Web-site footer. A chyron should remain at the bottom of the viewport only if it provides status, buttons, or control functions.

Design Rather Than Just Choose Your Solution

So which solution is best? I really can’t tell you. Your app or Web site is not like any other. For example, Google has its own unique requirements, and studies of user behaviors on sales sites are not especially relevant to the design of other types of sites.

Always design a solution. Don’t just choose a solution from the two options the framework provides. While this article details the three key scrolling options, there are variations and other ways of designing them. Occasionally, variants such as side-to-side scrolling are appropriate. Plus, there may be entirely different solutions.

Don’t judge a solution just because you love or hate it personally. Look deeper and discover the best solution for a particular app or site. Work with your whole team to define requirements and understand constraints.

Do not assume that anything about technology constraints is true. Look harder. I recently worked on a control panel with a 1-bit, or black-and-white, screen. Everyone assumed it would have to be characters only and not scrollable, but as cheap as the screen was, it had a modern technology core and could both display graphics and scroll windows. So, even for that screen, we could make the design follow modern principles.

Source: www.uxmatters.com

Author – Steven Hoober

Posted in Knowledge sharing | Tagged , | Leave a comment