Category Archives: Usability

Usability is the science and art of creating a better experience for the users of software. That experience is driven by the choices made during software development. These articles focus on the relevance and applicability of usabilty to all facets of software product success.

User Centered Design and Bridging The Canyon of Pain

Bridging the Canyon

There is such a thing as too much choice. For new users, too much choice (or control) is too much. For experienced users, too little choice is a problem. Ease of use usually comes from reduced control – but users don’t stay “new” for long. There’s a “canyon of pain” to quote Kathy Sierra in that transition from “new” to “experienced.” We call them “competent” users and we have to help them cross the canyon of pain.

Kathy’s Canyon of Pain

In her article on how much user control is too much?, Kathy talks about how hard it is to make the transition from a new user to an experienced user. We twist that idea into a discussion of feature prioritization. To illustrate her point, Kathy uses a great visual to get the point across.

Bigcanyon

On the other extreme is Apple’s iMovie. It gives you almost no control, but the payoff is high right out of the shrinkwrap. It exceeds my expectations of pain-to-payoff. But pretty quickly, anyone who gets into iMovie–and is bitten by the movie-making bug–starts wanting things that iMovie doesn’t let you control. So… Apple says, “not to worry — we have Final Cut Express HD for just $299”. The problem is, the learning curve jump from iMovie to Final Cut Express is DRASTIC. There needs to be something in the middle, to smooth that transition.

Kathy Sierra, How much control should our users have?

This is a fantastic visual, and allows us to steal an idea from market segmentation.

Market Segmentation Model

We presented the following chart in an article about how Microsoft is segmenting the market for Visual Studio (a software development environment).

Good Better Best Market Segmentation

Apple’s iMovie is in the “Good” box, and Final Cut Express HD is in the “Best” box. The problem is that users will grow out of the “Good” box, with no “Better” box to move into. Redrawn to illustrate (imagine this is an arial photo of Kathy’s canyon diagram):

canyon of pain

Kathy describes this in the context of moving from one product to another. The same dynamic will take place within a single product as users get more experience. Imagine a product that provides “limited but easy” stuff for new users as well as “full power” for experienced users. How will you get your users across the canyon of pain, when they are ready to start doing more with your product?

Features For Competent Users

A product that is designed with a focus on new and/or experienced users will have this canyon of pain. Competent users need a way to do more than when they were new users. And it needs to be easier than if they were expert users.

By developing features expressly for competent users, you create a bridge across this canyon of pain.

Bridge of Competence

There’s another reason to make sure you build this bridge for competent users.

competent users on bridge

Most of your users will be competent. Users don’t spend very long being new. They quickly want to walk across the bridge, in hopes of doing more. But only a very small percentage will invest the time and energy to make it all the way across the bridge and become experts. Most users will reach a level of competence and stay there.

If you don’t design features for those competent users, they will be in the canyon of pain, instead of enjoying the view from the bridge of competence.

Minimizing the Size of the Canyon

In an earlier analysis of the right number of features to include in a product, we looked at ways to increase the number of features without making the product overly complex.
shifting the curve

The article goes into more detail, but essentially what you are doing is making it easier for users to do more stuff with less effort. This encourages more users onto the competence bridge, and helps them move further along it as well (less effort to become an expert).

By improving features that are already there, you make it easier to get better at using the tool.

improved performance

Conclusion

By improving performance, you raise the utility for the users, ultimately making the bad parts less painful, and the good parts more rewarding.

Both of these approaches focus on improving existing features, versus adding new features. The challenge is to incorporate utility with ROI as part of your prioritization activities.

Usability Sells Software – Word of Mouth Marketing

for sale

There are three main models for selling software. You can hire a direct sales force. You can spend a lot on marketing and advertising. You can let your users sell the software for you, a technique commonly known as viral marketing. There’s a catch with viral marketing – users have to like your software.

Viral Marketing

We wrote an article in 2005, Ideavirus – Marketing By Word of Mouth, where we talked about a presentation by Seth Godin.

Some really key points he makes –

  • The idea vectors from user to user (slide 29)
  • The more you give your idea away for free, the more valuable it is (slides 32-33)
  • Build the mindshare first, then monetize. “get cash now!” cripples the spread of your virus (slides 36-40)
  • Seth gave his book away instead of selling it – 200,000 downloads the first two weeks (slide 55).

Seth may be the authority on viral marketing today. When he combines his work with Malcolm Gladwell, we get a great extension of the idea virus concept:

Seth Godin spells out the virus analogy. Someone uses a product or service and raves about it to his friends and associates. This is called sneezing. Some people only sneeze occasionally. Some people sneeze all the time. Some sneeze quietly, some loudly. Some sneeze to a small crowd and some sneeze to a huge gathering.

Karl Palachuk

Its the sneezers that spread the virus. But what makes people want to share?

Compelled To Share

People want to share the virus when they love the product. Gladwell talks (I think in The Tipping Point, but I don’t have it in front of me right now) about how some people are predisposed to sneezing. They will tell us all, good or bad, about the products that generate enough emotion for them to feel compelled to spread the word.

This sounds pretty scary – customers telling everyone about our product. What if our product sucks?

BazaarVoice, a company in Austin, issued a press release a while ago – “Positive Online Reviews Outweigh Negative Reviews 8 To 1.

Analysis across a diverse set of products and services indicates that positive reviews outweigh negative reviews 8 to 1, with an average rating of 4.3 out of 5 stars across all live Bazaarvoice clients.

[…]

“We are seeing a ‘Rating J-Curve’ across many clients in diverse industries,” said Sam Decker, vice president of marketing and products at Bazaarvoice. “The distribution looks like a J on a graph, where you see a low volume of 1 star reviews, fewer 2 and 3-star reviews, and a huge jump in 4 and 5-star ratings. While surprising at first, this finding agrees with third-party studies that suggest word of mouth is much more positive than we often assume.”

Sam Decker (Who also has a great blog)

If you’re still gun-shy, even though we know the odds are in our favor, there are ways to make our software not suck.

Comprehension Through Contrast

There’s a great visual in an article at 37signals titled In-store good or at-home good? that puts this all in perspective, when compared to traditional marketing approaches. The article sites an analysis from the Harvard Business Review.

They contrast the imact that the number of features has on two different personas. The buying persona, and the using persona.

  • The buying persona perceives more value (at the time of sale) from having more features.
  • The using persona experiences more value (over time) from having fewer features.

This is the basic premise of the more is less argument. We can step back and generalize this a bit.

Software that is more usable grows in value to users over time

Usability Sells Software

The buying persona is the target for marketing and advertising. She is also the person that a direct sales force tries to convince to buy our products. That’s why marketing is always asking for more features. They want products that appear to be more valuable, because perception sells.

But buyers aren’t sneezers. Rarely does a friend call and say “I just bought this, and I haven’t used it much, but you have to get one!”

The idea virus is vectored by users. And users grow to like the product more and more over time. And the usability of the product has a major influence over how well they like the product. The more usable it is, the more word of mouth marketing we get.

Bad Usability Calendar From Netlife Research

January from Netlife Research

What a great way to demonstrate 12 key usability concepts – creating a calendar where each concept is demonstrated.  You’ve heard the saying – “If you can’t be a good example, be a horrible warning.”  Here is that saying manifested in calendar form.

The Calendar

A Brilliant presentation of the importance of usability.  Brilliant because it is fun, and the ideas are all extremely well executed.  Thanks to Netlife Research for this!  And a hat tip to Jesper at justaddwater.dk.  Netlife’s main site is in Norwegian, which will be a pleasent surprise for some of our readers.

The other twelve months of the calendar are available in a pdf (go to justaddwater.dk to get the download), and are really great.  My favorite ideas (cleverly done in calendar as examples of how not to do it):

  • Give All Pages Suitable Titles and Subtitles
  • Don’t let news and information take up too much space from the main focus
  • Use a language the users understand

Genius.

Thanks, Jesper, and happy birthday – the one year mark is a big deal for a blog!  Jesper’s current “highest traffic post” is a roundup of 30 ajax tutorials.  Let’s see if we can push the bad usability calendar to the top of the list for year two of justaddwater.dk.  Go check it out!

Goal Driven Upgrades

upgraded seat

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.

Background On Documentation

Over the last couple of days, we’ve written about how to structure documentation to define what users can do with the software, instead of capturing what the software can do for users. This reverse approach uses user goals to guide our documentation. We also presented, more concretely, how to trace and manage our goal-driven documentation with use cases.

We can leverage this documentation approach to achieve two additional benefits:

  • Encourage users to install new upgrades
  • Encourage users to migrate from other applications to ours

The same factor is at play in both situations – users already know how to use their existing software, either a previous version of our software or a competitors software. The fundamental question for users is “How will I do what I need to do?” This is a major barrier to both upgrades and migration from other applications.

Kathy On Upgrades

Kathy’s article on why users don’t upgrade is awesome. She creates a great visual graph (shared via her CC license) of the user’s perspective on upgrades:

Sierra's Graph

Why they don’t upgrade (and what to do about it)

Kathy goes on to list several approaches to address the problem, all of them fall into either “make them want it” or “make it easier.” We will focus specifically on how writing goal-driven documentation can help.

Make Them Want It

We must apply the same prioritization approach to defining upgrades as we do to defining the initial release. This assures that the most valuable not-yet-implemented goals are addressed in the new version of the software. If we are using Kano as a framework for prioritization, we have the added benefit of effectively lowering the suck-threshold.

Make It Easier

We can make design decisions that make software easier to use. We can also follow Kathy’s other good suggestions. And we can write our documentation to make it easier for users to make the change.

Goal-driven documentation has two effects on the curve Kathy drew above. Here’s the same curve, representing a typical software upgrade:

typical upgrade

With goal-driven documentation, the curve is shifted up and to the left:

shifting the curve

This shift can be analyzed as two different factors:

two factors

The goal-driven documentation allows users to climb become more competent more quickly – effectively lowering the suck-threshold. When applied to upgrades, it reduces the size of the drop – preventing users from re-entering the suck-zone.

Faster Climb

Competence is not a measure of how quickly users can do everything the software can do – it is a measure of how quickly users can do everything they need to do with the software. When we define our software to prioritize solving the most valuable problems for our customers, we are defining the set of activities that the users need to do. And we identify this as a set of use cases.

We then document how users will follow those use cases, with the implementation we’ve given them.

structured doc

This goal-driven approach to documentation helps users climb the competence curve much faster, immediately reaching the “Finally I can actually DO something” point (above the suck threshold). As long as we document the right somethings, we’re all set.

Shorter Drop

We apply this same approach to our upgrades. Those use cases that we’ve added in a new release yield new documentation. Those implementation areas we’ve modified as part of the upgrade yield updates to previously released docs.

Users will have an easy answer for “how do I do it now?” as well as “What can I do now?

Collateral Benefit

We also get the benefit of making it much easier for users to migrate from other software packages (not just our earlier releases). There are books out there where authors address exactly this problem – Microsoft Word for Wordperfect Users and Java For Cobol Programmers come to mind. By showing users how to do what they need to do, we make it easy for them to switch.

Conclusion

  • Goal driven documentation makes it easier for users to learn how to use our software.
  • Goal driven documentation makes it easier for users to switch from other software programs to ours.
  • Goal driven documentation makes it easier for users to upgrade to new versions of our software.

Flesh Out Those Wireframes

Wire frame man(John Richards)

Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.

Hooked From the Start

Stephen starts his article with the following quote…

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

A very solid opening to his position that when you only use wireframes, you introduce problems. Wireframes are designed to eliminate problems and “clutter” from the feedback session. Feedback sessions provide us with a lot of information, and the challenge is to separate the noise from the signal. The goal of wireframes is to eliminate sources of noise, to make it easier to focus on the signal. But using wireframes also introduces noise into the data.
He goes on to provide a real world example of a website under development for Verizon – showing wireframes and “low fidelity prototypes” that include more information than just the wireframes.

Why Wireframes?

Stephen makes an interesting point – wireframes (named after 3D modeling techniques) were initially designed to provide quick feedback and insight into 3D models, without the expense of complete rendering. As technology reduced the cost of of rendering, rendering cycles began to replace wireframes as early prototyping tools.

A wireframe, in the user interface world, is a minimalist visualization of a website or application. It shows where information will reside on a page, and what information will be shown. When using a wireframe to get feedback, it allows a designer to (attempt to) isolate the feedback about content and layout from other data (like feedback on color schemes and graphics). It also allows for more rapid prototyping because the prototype can be built as soon as a layout is done, without waiting for colors and graphics and branding to be incorporated into the design.

Why Not Wireframes?

Expanding on Stephen’s point, the lack of information detracts from an understanding of the usability of a design. Colors (such as blue hyperlinks) do provide visual cues for users. Branding and navigation elements provide a sense of context and comfort. The absence of these things can distract the people we were trying so hard to not distract.

What About Cost?

Another goal of using wireframes is to reduce the cost (and time equals money) of prototyping. Stephen shows how in less than 15 minutes, a wireframe prototype is converted into a prototype that leverages existing branding, navigation, colors, and images. 15 minutes is not a long time to spend to achieve this striking difference (check out the images in Stephen’s article). When showing multiple screens in a site with structured navigation, most of those investments will be re-used across multiple screens.

Why It Will Work

The ability to re-use the “extra bits” is the key to why it will work and not just the key to why it won’t cost more.

People who think about website advertising worry a lot about ad-blindness, or the ability of people to ignore ads over time. We actually depend on it here, to allow our regular readers to tune-out ads that appear in consistent locations and formats and instead focus on the content of the articles. This same phenomenon applies to these augmented wireframes.

The lack of context that a wireframe creates can be disconcerting or even confusing. The (valid) concern that drives the use of wireframes is that providing all the other stuff will distract the users and prevent them from providing feedback on content and layout.

The ad-blindness effect will quickly allow people to ignore the “other stuff” and focus on providing feedback on the content and layout of a page. People are good at scanning pages – they have an autopilot that takes them directly to the “meat” of the page. And the presence of the extra content allows them to do that – where the absence of that richness will immediately trigger a “what’s wrong?” or “what’s different?” analysis.

manikin

Tips to Making It Work

Stephen provides eight tips, which we really like. We are concerned about one of the tips – to use “real data” instead of fake data. I had always learned that real data risked distracting the users, who might fixate on the fact that you chose incorrect data to display.

Today, after a prototype review session, we got feedback from our reviewers that it would help them if we used real data.  The reviewers of our (fleshed out) wireframes were unable to visualize how the interface might behave with some real-world data examples. The data we were presenting and manipulating is fairly complex, and the contrived examples didn’t do a very good job of showing how the interface would handle the complexity it would need to support.

Using representative data is definitely a good idea – and as good as Stephen’s other ideas are, we’ll take his word for it that real data is even better.

Conclusion

Spend the incremental effort to make wireframes “feel real” by fleshing out some of the context that wraps the prototyped pages. That context will provide more comfort than distraction for users.

Office 2007 UX Victory

office 12 video

Microsoft Office 2007 has a completely new user interaction paradigm.

The old interfaces for Microsoft Office 2003 (and earlier) organized the menu structures around features or capabilities. Each grouping represented tasks that appeared to be related in functionality. This, unfortunately, doesn’t help the user very much. The new interface is very task based, and organizes capabilities based upon the task the user is currently performing. What the Office team has done is innovate. And the innovations differentiate them from every other business application I’ve ever seen.

Check out the 13 minute video from Microsoft’s user experience team here : http://www.microsoft.com/office/preview/ui/demo.mspx. It’s worth watching!

The best quote, from Jensen Harris, lead program manager, Office user experience team:

We realized that people weren’t trying to find commands in the product, they were trying to get great results.

This really captures the spirit of the changes – and they are compelling and dramatic!

Julie Larson-Green / Scoble interview on Channel 9

Robert Scoble filmed a 41 minute interview and demo with Julie Larson-Green, manager of the Office user experience team (Sep 2005). The comment thread on this Channel 9 post is really interesting, including several people expecting to be unimpressed, and ending up being converted. If you only watch one video, watch the other one. If you’re the kind of person who re-watches a DVD to listen to the director voice-over the decisions, check out this one too.

Jensen Harris has a blog devoted to Office 2007

After you watch the video, and decide that you must have this app (and you will), subscribe to Jensen’s blog to stay up to date. He provides great insight into how the UX force at Microsoft has driven these changes and why. A great post to start with: Ye Olde Museum of Office Past (Why the UI, part 2). Note that it is a repost of an earlier article he wrote, but it is still fun to look back at the evolution of the Office UI.

Conclusion

Suddenly, open office seems much less compelling. The Office team has put together very compelling and differentiated innovations. It isn’t the ribbon (replaces the menus and toolbars) that makes it exciting, its the task-centric design of the application. The new UI puts Office 2007 clearly in the revolutionary change corner of the magic square of innovation.

Foundation Series: User Experience Disciplines

requirements classroom

What the heck is UX?

UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. In some circles it is known as human-factors engineering, applied to software design. There are several disciplines within this field, we’ll introduce each of them.

We talk about the different roles within this field in several posts throughout Tyner Blain. The following are introductory explanations for these roles.

Information Architecture (IA)

The study of information and it’s presentation to people. Also the study of how people interact with information. Many software packages allow users to manage complex information. Information can be presented in ways that make it easier for people to absorb and understand.

As a very simple example, imagine a website that allows you to research the cost of living in different cities in the USA. There are thousands of cities in the country. IA helps with designing a user interface that allows users to get information for a specific city. An IA specialist would recognize that cities can be organized by state. In fact, cities in different states can have the same name, like Springfield, Missouri and Springfield, Illinois. But two cities within the same state won’t have the same name. This insight can be applied to present a design where the user selects a state first, which then filters a list of the cities within that state.

A corporate internet may really be the combination of several different standalone websites – a company news bulletin or blog, an interface to the HR system, a download center for installing corporate-approved software, an email directory for the company, etc. IA specialists will determine how to organize all of these functions so that employees can intuitively find what they need and get as much benefit out of the site as possible.

Usability

The study of what makes software easy to use or hard to use. A usability specialist will look at the tasks that a user needs to perform, and analyze the most intuitive or efficient ways to perform them. Think of the sequence of steps that you take when adding a graph of data in Microsoft excel. There is a wizard that walks you through a series of questions in order to create the graph for you. A usability specialist determined the best sequence in which to ask and answer those questions.
Usability specialists will also make holistic assessments of how an application or suite of applications behave. This helps users gain competence or mastery of software more quickly. All of Microsoft’s applications use the same approach for opening and saving files (same menus, same shortcut keys, same dialogs, etc). This is the result of usability analysis.

A usability specialist will also be the person who determines how to make software great for novice and experts alike. This is critical to having successful software – the experts are the people who will promote your software for you, but they won’t become experts unless they survive the novice-user break-in period.

Graphic (or Visual) Design

Some people erroneously think of visual designers as the people who make software sexy. The can certainly do that, but graphic design is as much about creating emotions for the users, consistency of presentation, and establishing elements of brand as it is about sexy. This is what makes a Macintosh look like a Macintosh (while usability specialists make it great to use).

A graphic designer can create a set of consistent icons that make an application feel professional, and make the user feel whatever the designer wants. Graphic designers can make the user interface feel different enough to create a notion of uniqueness and branding (association of the images with the product or company), while also keeping them consistent enough with “everybody else” that users know what to do. Another technique is to create an affordance visually. An affordance is an image or element that suggests an action. A dial says “turn me” while a slider says “slide me.”

This can be very subtle and very powerful.

boring scrollbar

Think about scrollbars for a second. Most scrollbars have a pretty boring look. There are tiny up and down arrows at the top and bottom – which create an affordance that says “click on me and the window will move up (or down). That’s good design. There’s also a grey bar in the middle. In some user interfaces, the size of that bar is proportional to the amount of the content that is currently visible. This gives the user some insight into how much content is hidden – another good visual design. A user can also click and drag the grey bar up and down to move the contents of the window. There are no visible cues that this would work, a user would have to be shown that this works. Another example of “hidden” functionality is the ability to click in the light grey “background” of a scrollbar – it causes the contents of the window to page up or page down. Again, without training or an errant click, people would not know this.

cool scrollbar

If we make a tiny change to that scrollbar by adding a few lines in the center, we create a tactile effect – implying that the user can “grab” it with the mouse. This scrollbar screams “grab me”. Subtle, but powerful.

Interaction Design

Interaction Designers are a different breed.  They focus on the software at a higher level, using a goal-driven process to focus on the intent and objectives of the users.

– – –

Check out the index of the Foundation Series posts which will be updated whenever new posts are added.

Death by a thousand cuts: Usability problems add up

pincushion

In Those “Minor” Usability Annoyances, Daniel Read at developer.* writes in on a topic that resonates with me.

Daniel describes working on a critical application with multi-year, continuous development and a couple hundred internal users. I’m currently helping a client incorporate automated unit testing for a similar enterprise application, and Ive helped teams manage the fixing of the same kinds of problems.

Daniel describes how a multitude of small usability problems add up to make the application all but unusable, one user even describing himself as a victim of the system.

He has some good insights into what’s wrong and suggestions on how to prevent the mistakes. He also provides a sample of approaches on how to fix existing problems.

We recently covered some major usability blunders and solutions too.

Top five usability blunders (and fixes)

frustrated user

Five easy steps to alienating your users with bad usability

  1. Fail to simplify a comprehensive interface so that new users can quickly climb past the suck threshold.
  2. Build an inconsistent UI layout or interaction design that varies throughout the application, creating a sense of dissonance for the users.
  3. Interrupt the user‘s workflow with pop-ups and other modal interruptions.
  4. Limit expert users to following “new user” workflow, one tedius, repetitive step at a time when shortcuts would work.
  5. Don’t suggest solutions when an error message is displayed.

Five difficult steps to making your users fall in love with your application

  1. Plan for new users. Incorporate training, documentation, guides (or wizards), and feedback (breadcrumbs, confirmations) into your design. All of these “new user” solutions can be ignored once the users become experts.
  2. Plan a consistent UI. Share a common stylesheet across web pages. Keep screenshots of the application taped to the wall where UI designers and developers can quickly assure commonality. Reuse interace code – derive from (or reference) common search widgets, sortable grids, etc. Make sure part of design reviews explicitly ask “is this the same as what’s already there” or “are we updating the existing stuff to match this?”
  3. Provide passive warnings. Provide feedback in the status bar or page header when something “might not be right”. Add “Don’t ask me again” checkboxes to the “Are you sure you want to do this?” interuptions – let each user decide when they know what they’re doing and don’t want the interruption. Add undo capabilities for when users mess up.
  4. See #1‘s solution approach.
  5. Add a “Fix this for me” button whenever a modal message must be displayed. At a minimum, offer targeted advice on how to fix the problem manually – right in the dialog. Add logging of all modal interruptions, so that developers can design new automated fixes (or prevent errors entirely) in future releases.

Getting Past The ’Suck Threshold’

Kathy Sierra writes a great post in her blog, Creating Passionate Users, that talks about the requirement to make things interesting.

The driving objective is to accelerate the user adoption curve – which Kathy calls the Kick Ass Curve. Any user is initially forced to focus on the tool, and not the task. The better the design of the tool, the faster they can master it, forget about it, and focus on the task at hand. Her graph brings it home – initially, users are frustrated and unproductive. Until they gain enough competence with the tool, they are trapped below the suck threshold. They climb into competence, and eventually to mastery.

The amount of time it takes them to cross this threshold can be a proxy for the difference between sucky software and great software.

Microsoft Office uses commonality of interface very effectively to shorten the time in the suck zone. Each application has a ton of “learn the tool” material – and by using a common set of menus, commands and experiences, the Office team dramatically reduces the sucking time for new users. Once you can save a spell-checked word document, or a presentation with a stock template, you are likely to have crossed out of the suck zone. And the familiar commands required to do that are in familiar locations.

When designing web applications, the flexibility to do “anything” makes it easy to do unconventional things. We can use interesting to help the users cross the suck threshold. Kathy talks about some ways to do it. Maybe they don’t all easily apply in our particular case, but regardless, getting users past the suck threshold is critical.

In the consumer space, this can be the difference between having and not having a viral marketing effect. In the enterprise space, it can be the driver of user adoption rates (and if users don’t use it, there goes the ROI argument for the project).