Introducing Agility into Requirements Definition

Executive Summary

Much focus has been paid in recent years to the introduction of Agile methodologies into the overall software project space. The bulk of these methodologies focus on quickly generating ‘code’ that can be tested. However that alone does not fully accomplish all the business goals, of a project. This is because not as much consideration has been given within Agile methodologies on traditional ‘Requirements’ stages, or if in fact ‘Requirements’ even belong in the discussion.

This paper sets out to recap the business value of Agile, and then express how the same benefits that Agile provides to the overall lifecycle can and must be introduced and implemented specifically within the Requirements Definition function.

Agile, at the conceptual level
In 2001 the Agile Manifesto was launched, whereby 17 “organisational anarchists” defined four values for better ways of developing software:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The result of many years of Agile methods momentum has produced flavors such as Scrum, Crystal Clear, XP, ASD, FDD, DSDM, etc. Additional entries have included OpenUP / RUP, Lean, EVO, and The Eclipse Way. Collaborative practices are key in them, and many have jumped on the opportunity to be what they think is “faster and cheaper.” In some cases this led to fragilism.

A good definition of Agile at its highest level is: an iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce project deliverables in a cost effective and timely manner which meets the changing needs of its stakeholders.

Core principles of this therefore include:

• “Fits just right” process – Do the simplest thing possible, Self-correcting teams
• Continuous testing and validation
• Consistent team collaboration – De-emphasize ‘meetings’
• Rapid response to change
• Ongoing and useful customer involvement – active customer involvement is imperative! – find a champion, Nothing counts until you deliver software
• Frequent delivery of working product – Weeks rather than months; days rather than weeks

In a traditional lifecycle of a project, risk is delayed. Much activity occurs “up front,” whereby design and construction occur in a vacuum. Architecture and functionality is not “seen” until near the end of the lifecycle. Contrast that with Agile, where candidate architectures are revealed earlier, serving to expose potential problems. The gap between these two approaches can be seen as the amount of risk reduction that can be salvaged.

Finally, there are some concerns to face, regarding Agile. Many of these are misconceptions, however:

• Uncontrolled Change
• Chaos – No process
• Develop with insufficient requirements
• Developers run the show
• Process itself becomes the goal
• Placebo effect
• Key point gets missed

So what should be the fit, with Requirements Definition?
As Agile increases in popularity, there can be a belief that stringent Requirements processes can be seen as overhead. A mistake can occur whereby there is the feeling of a need to ‘rush’ almost directly to development, and Requirements only serve to slow things. This misses, however, the need for business side users to (still) connect with their external development partners/organizations. So regardless of Agile’s speed to market benefits, business subject matter experts still have to play an important role; which dictates that they must have a place at the table along with development providers.

The problem with traditional ‘Requirements’ activity
The underlying problems with traditional Requirements Definition are distilled into three main causes:

• Misunderstood product requirements due to ambiguity of written specifications
• Lack of sufficient information to support complex applications/systems
• Inability to “test drive” a product design with customers and stakeholders before development

One can easily see that the above issues are not Agile, in philosophy.
Additionally there exists a desire by project teams to always minimize ‘change.’ This desire leads to an attempt to define everything up front. Agile methods can improve on this through iterations that stagger ‘commitment.’

After years of experience at OneSpring, we feel we’ve learned a better way.

We call this approach the Stream Process™. The Stream Process™ is a methodology that offers companies a collaborative and highly-visual approach to creating superior products and solutions in less time, with reduced project re-work. This helps companies dramatically improve productivity, quality and customer satisfaction.

Stream’s core process is made up of three areas: Insight, Clarity and Focus. Each of these areas are performed in a Realization Cycle. The output of a Realization Cycle is the Definition. Each time a full Realization Cycle is performed, an iteration of the Definition is achieved.

The output of each Realization Cycle is “delivered” to the stakeholders. Unlike a SDLC (Software Development Lifecycle), however, this output is not delivered to the development team with the intention to code from, but rather delivered to the consumers of the requirements definition (e.g. business, customers, IT).

The purpose is to achieve a common understanding before beginning to code. Once this common knowledge is achieved by the team of stakeholders, the Definition may be used for IT architecture/development. In other words the inputs for development – user stories, use cases, etc. – are now stronger. Visualization has mitigated the risk of missing out on the real business goals.

This scalability and flexibility therefore allows StreamTM to easily be integrated within any organization using Agile based methodologies, or to in fact introduce Agility into an organization who has not yet taken this path.

Some Agile proponents might argue that there is no Requirements Definition ‘stage’ with an Agile approach. We find that stance to be unrealistic at best, and foolish at worst. Defining requirements is where it all begins. Without that, what are you designing/negotiating/working for? An aimless, amorphous goal? How will you know once you get there? How will you know if you don’t?

Others will focus on ceremony, and state that since visualizations do not automatically turn into working ‘code’ they aren’t of value. This is naïve, for a Visualization prototype that all stakeholders agree on and take ownership of does provide a detailed blueprint that can provide immediate value, without need for ‘translation.’
Therefore and in conclusion, we propose the following analogy:

• Agile approaches, regardless of the flavor, apply to the development lifecycle as a whole
• The Stream Process™ introduces the concepts of Agility via a specific set of activities, to the Requirements discipline of the lifecycle

General Sources:
http://agilemanifesto.org/ http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods http://www.ibm.com/developerworks/rational/rationaledge/ http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf

Software Visualization Defined

Executive Summary


Software visualization, also referred to as just “visualization,” is quickly becoming one of the fastest growing and most widely talked about technologies within IT today. Visualization is the process by which software applications are defined “visually.” I stress the word “visually” because traditional methods have, until now, dictated that software is defined “textually.” The process of visualization makes use of specialized tools that allow project teams to quickly define user interfaces, as well as user interactions, without writing any programming code.

Visualizing software is a relatively new concept. One of the precursors to visualizing software was prototyping, however prototyping is now going the way of the dinosaurs in terms of its usefulness and cost effectiveness. The primary distinctions between visualizations and prototypes revolve around who creates them and when in the lifecycle they occur. Visualizations are made to be highly collaborative and easy to modify based on changing requirements and project demands. Competition has also driven companies to think about developing software faster and cheaper and finding new ways to do it. The need for enhanced user experience has also been a driving force behind this trend. As consumers demand more from their interactions with software, the need for more user-friendly applications has grown exponentially. Technology has also become so advanced over the past 10 years that just about anyone can develop software. Both large and small companies are now able to compete at the same level in terms of bringing their ideas to market faster than ever before. This dynamic has changed organizational priorities so companies can now focus on how to be more nimble. Also, barriers-to-entry have lessened due to these advancements. The evolution of visualization is playing a key role in these trends because it is equipping companies with the ability to quickly develop concepts and ideas in less time and at lower costs.

This article outlines the latest trends in the visualization space and identifies key concepts along the way. How are companies and individuals using visualization to advance their goals and objectives? What types of ROI’s are companies realizing because of this trend? This, and other examples are discussed below.

Key benefits of visualization
The ability to test-drive software applications—or any user interface for that matter—has tremendous value within business and is at the core of what visualization is about. This new paradigm gives companies the opportunity to quickly produce working simulations of concepts, ideas, and existing applications without a large investment and by using minimal resources. It also allows businesses to quickly evaluate concepts with real users prior to any development taking place, thus reducing costs.

The ability to quickly visualize software is turning traditional software development processes upside down. The original target group for this technology was IT, but it is now taking hold within business groups, such as marketing and operations. Until recently, these groups have had no way to create working concepts of ideas for software or web applications that could solve their business problems. Reliance on IT alone to prove out concepts has been typically slow and expensive. Here are some of the benefits these groups are realizing.

The ability to quickly design and test-drive concepts without getting IT involved. We’re talking days, not weeks or months.


The ability to conduct user testing prior to spending enormous amounts of money on developing applications with programming code such as PHP, JAVA, .NET, scripting, etc.

The ability of business users to take part in the creation process. Since anyone can learn how to visualize, business owners are taking increasing ownership in building working visualizations.

The ability to simulate COTS applications without any customization. Think about test-driving SAP™, PeopleSoft™, or SharePoint™ without actually installing and customizing any code.

How is visualizing software different from prototyping software?

The main difference between visualizing and prototyping software applications resides in the people and tools used. Prototypes are traditionally created by a developer or group of developers. This typically increases the cost and the time needed to view and interact with a concept or idea. Prototyping also usually occurs after significant time and money has been spent defining textual requirements. However, the benefit is that (most likely) reusable code will exist after the prototype is developed that can be used in the finished product.

Visualization, on the other hand, is the concept of visually defining software or web applications prior to development. If you look at a traditional software development lifecycle (SDLC), visual depictions of an application occur some where during the “design” phase. Visualization fits within the “define” phase—much earlier in the process. This distinction has real dollars associated with it that can help justify the visualization techniques. There is also the distinction of fidelity. Visualizations also allow team members to quickly increase and change the fidelity. Users can quickly import and swap graphical elements, as opposed to prototypes which may require coding changes.

Visualizations can be built by anyone—even those with limited or no development experience. It also occurs early in the lifecycle, where the cost of change is significantly lower. Figure 1.0 illustrates the reduced “change cost” associated with visualizing in contrast with prototyping. A change to the application during the prototyping phase can significantly increase cost for two primary reasons: 1) you must include development resources earlier in the project lifecycle, and 2) any change to the prototype will have to be made in the textual requirements defined earlier in the process. The latter in a larger project can cause extensive delays that directly affect the project’s budget. Controlling and enabling flexiblilty earlier in the lifecycle reduces the overall cost of a project.

The future of Visualization
Let’s face it—a lot of us have become dependent on technology. It is part of our daily lives. We interact with software throughout the day. I’m not referring to just websites and computer software, I’m referring to such things as our cell phones, GPS devices, televisions, etc. As consumer electronics become more sophisticated, the need for better/simpler user interfaces will grow. Think back to the first generation handheld GPS devices. Most were clunky and the menu of options were difficult to navigate. Such devices have become easier to use as advancements in technology have matured and the demand for easier-to-use products has grown. The good news is that companies are starting to respond to consumer demands to make products and software more user friendly. This is at the core of the user experience design approach, to which visualization is well-suited.

Visualization is currently going through its next phase of maturity. As computer systems and software become more integrated into our daily lives, the need to test-drive these systems will grow. Companies are starting to realize they can use this software to visualize anything with a user interface—for example, ATM machines, cell phones, microwave interfaces, remote controls, GPS devices, etc. The goal of this technology is not to replace traditional computer-aided design (CAD) software, but rather to gain valuable information by allowing users to interact with software products, ideas, and concepts prior to making large investments in the building of them.

AjaxWorld: User Experience & RIA’s: How does it all come together?

"You don’t have to be a designer, you just have to design the right things, well."

Presentation Materials:

• Interactive Presentation (16.1MB QuickTime – Wait for it to load and click the slides to progress)
• Presentation (3.7MB PDF)
• Roadmap Planning Document (78KB Excel)
• User Thumbnail Capture Document (72KB Excel)
• Project Scoping Document (72KB Excel)
• Application Evaluation Document (88KB Excel)

Reading List:

• Don’t Make Me Think – Steve Krug
• The Inmates are Running the Asylum – Alan Cooper
• Web Application Form Design – Luke Wroblewski
• Designing Web Usability – Jakob Nielsen
• Information Architecture for the World Wide Web – Louis Rosenfeld
• Information Design Series (4 Books) – Edward Tufte
• Designing Interfaces – Jenifer Tidwell
• Handbook of Usability Testing – Jeffrey Rubin

5 Myths of Rich Internet Applications (RIA)

5. RIA’s provide the perfect vehicle for sexy,splashy sites
4. RIA’s bring people-centered design to information workspaces.
3. If you’ve designed web sites, you can design RIA’s
2. It’s just like our software! Of course our users will understand it!
1. Because of their very nature, RIA’s provide a better User Experience
than traditional HTML sites.

Webcast Date: Tuesday, March 18, 2008 3:20 pm; MyCatalyze.org

Duration: 59 mins

Description: What are Rich Internet Applications or RIAs? Are they the panacea for everything that ails us? User Experience expert Laurie Gray from OneSpring discusses some of the most common attitudes toward RIA’s and addresses the 5 biggest myths surrounding this exciting technology.

The Software Requirements Struggle

Executive Summary
Traditional software development has always required a long requirements-gathering phase at the beginning of a project that, if not handled correctly, can often result in schedule delays and costly budget overruns that have a significant impact on the project itself. Software simulation can streamline that process and prevent many of the errors and delays that are common when using traditional methods. This paper details the requirements-gathering mechanism and how simulation is breaking into the mainstream as a time-and cost-saving method of helping clients design software projects with a minimum of error and hassle.

Traditional Software Requirements
Most of us in the software industry are familiar with the concept of requirements and the traditional process of defining requirements for software development projects. In the world of software development, requirements are the blueprints the development team uses to create software. Requirements identify the specific functions that a software program is expected to carry out as a person or system interacts with it. In more concrete terms, requirements identify the building blocks that are used to create software applications, and the processes that each facet of the software will invoke as it is used or implemented in an environment.

The importance of requirements can be reflected in research performed by The Standish Group which found that 28 percent of software projects are completed on-time and on-budget. The cause of this atonishing number does not fall on requirements alone, but it certainly has a profound impact. In addition, OneSpring estimates that most companies that produce software spend at least 30 percent of their software budget on the requirements definition process alone. In most development projects, this can add up to a rather large sum of money very quickly. What many industry professionals also know is that the traditional requirement-gathering and defining process rarely creates a good enough snapshot of the product to prevent budget overruns and lost man hours that result from poorly communicated specifications in the early stages of a project.

Most companies that create software in its various forms write their requirements in basic text format— often using programs like Microsoft Word. The degree of detail in these documents varies in direct relation to the complexity of the project and the environment in which the project is being developed. Some projects can have hundreds of pages of documentation and many hierarchical levels that can get very confusing if not written clearly. The main problem with lengthy textual specifications, however, is that no one likes to read them, nor do many people have the amount of time it takes to thoroughly understand them.

Written requirements are widely recognized and understood as the first step in software design across the industry. In fact, some companies create vision documents that outline the scope of the final product and give developers an overall goal to shoot for, and then create a software requirements specification (SRS) or a functional specification that outlines the detailed requirements. These documents are usually cumbersome to put together and difficult to understand and interpret.

Communicating Concepts and Ideas Effectively
The process of gathering requirements is one of the most disorganized areas of most software development projects, and as a result, is often the most misunderstood. The process begins when someone—often an executive or manager in a company—identifies an area of the business that could benefit from the potential implementation of a new software solution or the enhancement of an existing software application. When an idea is presented to the powers that be in the organization and approved for development, a decision is then made to either build a custom application or purchase a boxed solution. Regardless of the outcome of that decision, the process of gathering and defining traditional requirements is equally important. The quality of the requirements documentation can result in the difference between a successful product launch and various high-dollar mistakes.

The purpose of developing new software is to create a business solution that either reduces overhead or creates new revenue—in other words, it either saves money or makes money. Why is it, then, that most software projects start out with good intentions but end up failing or going way over budget? The answer is simple—poor requirements. The process of gathering and defining requirements is designed to prevent such problems by clearly and effectively documenting the many details of a project before any development occurs. Attempting to reduce errors is a key component in any project plan, and software projects are no different.

Imagine for a moment that you planned your first home. You designed it from the ground up and you are very proud of your accomplishment. Now, imagine discovering that you never properly analyzed the amount of concrete needed to support the size of the house. Here you are with a new home, presumably ready to move in, and you find out the foundation is faulty. How much is it going to cost you to fix this problem? We don’t automatically know the answer to this question, but we can assume it is going to be very expensive. This is an example of a situation in which the requirements-gathering process was flawed. If you had spent more time analyzing the size and weight of the house in relation to the amount of concrete needed, you might have been able to prevent this problem before the first nail was hammered.

This situation is much the same in many Fortune 500 companies today. Despite incredible advances in software and hardware over the last 40 years, many companies still spend tens of millions of dollars annually to correct software development bugs and defects that often do not surface until well after the design phase is completed. There is nothing more frustrating in a software development project than discovering a bug or a defect that could have been prevented if the front-end research had clearly and adequately communicated the necessary specifications earlier in the process. The loss of money and time spent by design teams often causes projects to end up over budget and to exceed scheduled time allowances—causing launch delays and, in some cases, the scrapping of an entire project. Well-researched, well-defined, and well-documented requirements are critically important in preventing these kinds of calamities.

Issues with Traditional Textual Requirements
For years, traditional software requirements have been produced in textual form—written by analysts and administrative assistants through sessions held with business stakeholders. This process classically produces many pages of typed specifications and notes that add up to volumes of requirements that have to be waded through as the team progresses with the actual programming work. Traditional textual requirements alone, although necessary for documentation purposes, are fraught with issues that can have an impact on the success of the overall project.

The mass of paperwork, for example, is often too much to digest for the stakeholders who need to buy into a project. Executives who hold the purse strings for a project rarely have the time to wade through the pages of requirements that spell out what the program will do for them. The sheer mass of documentation also often hides unnecessary requirements or prevents readers from recognizing that a requirement might be missing. Different interpretations of requirements or differences in writing styles can often lead to misunderstandings and debates over the intent of a particular requirement and what its manifestation will be in the final product. The scope of a project can shift slightly when the requirements are interpreted incorrectly, resulting in an end product that looks different from that which the designer envisioned. These issues and more can have a profound financial and scheduling impact on a software development project.

Stakeholder Buy-in
One of the most challenging things with defining textual software requirements is obtaining stakeholder buy-in. Most stakeholders don’t read—or have time to read—the requirements. This is understandable, considering that most average-size software applications can generate hundreds of pages of textual requirements. Executives that control the money and make the decisions regarding the life expectancy of a project would need many more hours in their day if they tried to read and understand all of the software requirements for each project that they oversee.

One example is a recent project at OneSpring that included over 1,500 features. Picture us sitting with the stakeholders and the project team members trying to obtain buy-off on the requirements. During our first hour-long session, we made it through only ten features. This is only one example among the hundreds out there that reinforce the difficulty of reviewing projects with clients using a review of traditional software requirements.

In addition to just reading requirements, these executives also have to visualize what the requirements are describing and how they impact other areas of the organization. It is difficult to visualize the interrelatedness of the requirements, however, when faced with a mountain of textual documentation. Most individuals are visual rather than textual. This simply means that it is easier to decipher an image of something as opposed to reading about it—hence the saying, “A picture is worth a thousand words.”

Scope Creep
Scope creep is a problem by which stakeholders continue to add requirements to a project even after sign-off on requirements has occurred. This is an ever present issue that plagues many software projects and can lead to massive delays and budget overuns. The presence of a formal methodology can help prevent this from happening, but it is almost impossible to eliminate it altogether.

Unnecessary Requirements
It is very easy to slip requirements into a software project. The sheer scope and breadth of a long list of requirements makes it easy for stakeholders to slip additional requirements into the document without much notice. The focus of any project should be restricted to high-need requirements, rather than bells and whistles—at least at first.

Different Interpretations
Another problem with textual requirements is that the written word can be easily misinterpreted. Reading a list of 500 requirements and trying to visualize what the requirements are identifying easily opens the door for misinterpretation. It is the job of the business analyst to make sure that all requirements are interpreted correctly by all team members. The problem with this is that business analysts are human, and can also misinterpret information in written form.

Different Writing Styles
A fair number of projects have several individuals working on defining requirements, which opens up the issue of different writing styles. This could range from how requirements are actually defined to subtle nuances in writing style. This can also contributes to misunderstandings over what the requirements are intended to accomplish.

Maintaining Requirements
Maintaining a large number of textual requirements can be a daunting task in itself. There are tools in the market that can help facilitate this, but they are only as good as the amount of human attention that is paid to making sure the requirements are up-to-date. It is very easy to forget to update requirements, because updates are generally written down in meetings, in a notebook, or on a notepad during a phone conversation and then transferred to the master list later. This gap between writing the change down and manually changing the requirement is the difference where missed or misinterpreted requirements can occur.

Ambiguous or Lost Requirements
This is tied directly to maintaining requirements in that requirements can be lost or opened up for interpretation. For example, a stakeholder says “I want to be able to log into the system.” That simple statement opens up a great many topics for discussion. Should the login be single sign-on? Does the user have to register first before they log in or will they already have an account? These are just a couple questions that would have to be asked. A junior business analyst may not be experienced enough to know what questions to ask, or may miss the finer points of the questions they ask. Because of the sea of requirements that sometimes threaten to overtake some projects, it can be extremely easy to miss critical requirements. This usually comes to light after the software is launched and a client is reviewing the application.

It is very easy to get bogged down in the weeds with requirements. Many projects last months at a time and it can become increasingly difficult to discern the trees from the forest during lengthy projects.

This list of issues can create cost overruns, exploded schedules, or just annoying delays and misunderstandings. With such a long knock-list of concerns, are there any advantages to continuing to use a traditional requirements-gathering process? There is newer technology that offers an exciting alternative with many more benefits than the older, more problematic requirements-gathering activities.

Modern Software Requirements: Software Simulation
How many of you have found yourselves with an idea and no simple way to visualize it? Not so long ago, we would have taken the traditional approach of hiring a team of business analysts to document our new idea. The typical timeline would include numerous meetings talking about the product concepts, with a lot of note-taking by the team of analysts. Once the analysts felt they had fully captured your vision, they would have packed up the bus and headed out to craft a 300-page Microsoft Word document or something similar. In other words, we paid for the pounds of paper the consultants generated. After a few months, the lead analyst would reappear with a slick presentation and several copies of the 300-page document, and tell us that our product lies somewhere within those 300 pages. Although this approach has worked for many years, it is fraught with errors, ambiguity, and always a missed concept that leads to countless dollars spent in project rework.

Software simulation provides us with a viable alternative to traditional requirements with many fringe benefits. Software simulation is the process of visually defining a website, desktop application, portal, or any other product that contains a user interface. Simulations allow business analysts, product managers, and user-experience professionals to create compelling interactions without ever writing a single line of code.

The real power lies in the simulation’s ability to mimic (or simulate) actual data interactions. A business analyst, for example, can rapidly visualize what a user login screen [see Figure 1.0] or registration page will look like and how it will function when users log into the site and view recent activity. It is easy to visualize the scope of the intended final project early in the design phase with a simulation, as compared to the final product. The final product is created by programmers using requirements that are generated through the simulation process, resulting in a website that is extremely close to the original simulation without the budget overruns and schedule extensions that are classically inherent in traditional software projects.

The ability of non-technical professionals to create such feature-rich simulations in a relatively short timeframe allow project stakeholders to envision what the final product will resemble once it is developed. This negates the need for people who are not intimately involved in the details of a project to wade through reams of paper documentation—the visual representation of what the program or product will do can save hours of development time and often reduce development budgets by preventing rework in later stages of the project.

The benefits of simulating software rather than using the traditional documentation process are vast. This exciting activity is impacting businesses today in a number of ways, including the following:

• Allows users to visualize ideas instantly (Business Stakeholders, Developers, Architects, etc)
• Reduces time to market for most products
• Eliminates requirement ambiguity
• Reduces project rework
• Mitigates project risks
• Allows for early training
• Provides the ability to perform usability testing earlier in the process

In addition to the benefits listed above, many simulation products allow for robust requirements management. This provides a 1-to-1 correlation between the visual imagery created in the simulation and the necessary textual annotations that accompany the visual interactions.

OneSpring was created to harness the power of new technology in requirements management and software design. Our background with traditional requirements definition provided us with countless years of experience developing textual requirements (i.e., use cases). Hours spent cleaning up the results of documentation and design errors had provided us with a burning ambition to find and market a solution that could save our team and our clients many hours of development time. As a result, many of our consultants at OneSpring have moved away from traditional requirements definition and have adopted a methodology of starting all our projects in a simulation tool such as iRise or Axure.

The increased benefits of software simulation are slowly becoming a standard in many companies across the industry. As I have introduced in this paper, the most notable benefits are fewer defects and reduced development time. As most companies in the business of creating and developing software know, these benefits can add up to millions of dollars in savings and hundreds of hours in recovered time, resulting in much more successful projects and happier customers.

As a result of the new global economy, U.S. companies now must compete on a much larger scale with companies from around the world. The need to produce products faster and more efficiently has never been stronger. As a result of companies such as OneSpring, who are pushing the advantages of simulation over the old traditional requirements-gathering process, simulation is slowly creeping into the software development lifecycle of more and more companies and organizations. As exposure to it expands, so will its impact on the industry at large.

Best Practices in User Experience

Using Animation and Interactive Elements on Websites

Executive Summary

Interactive content can provide a highly compelling and exciting Web experience when implemented correctly. When implemented incorrectly, it can be distracting or frustrating, be viewed as self-serving, and ultimately lead to abandonment of the site and loss of a potential sale. In order to implement this technology properly, consumer intent and purpose must first be clarified. Once complete, this intention is distilled into use cases, which then are used to drive the design and development process. The result is a site that operates in harmony with the consumer’s expectations while providing a top-shelf, engaging, and entertaining experience. Consumers find what they need and marketers begin to realize their ROI on their development investment.

The face of media is changing. As users are bombarded by ever-increasing marketing messages, they are getting better at tuning out those messages and are instead preferring to utilize separate channels through which to gather product information. In an attempt to keep users looking and thinking about their products, media designers are trying to create more engaging experiences. As the dance becomes more complex, however, it’s easy to negate the efforts by not paying careful attention to the user experience of dynamic websites. This paper provides practical suggestions for taking steps to ensure that dynamic content engages the user in a way that is most meaningful to them.

Rich Internet consumption is on the rise
The Web medium has become an important part of many products’ overall product branding and marketing plans. For example, KnowledgeStorm recently found that greater than 70 percent of all technology buyers begin their research via the Internet (KnowledgeStorm, 2005), and this type of information has driven traditional marketers to view the Web in an entirely new light. Simply putting the product information on the Internet is not enough, however. Users expect interactive content and rich experiences (Rogowski, 2006). Rich Internet content is appearing across nearly all verticals, and it has been held up as a potential solution for marketers to increase conversions, reduce user abandonment, and improve user satisfaction (Rogowski, 2006). The interactive nature of this content makes it a particularly appealing application for sites advertising products that move, or that require user input to configure a custom-designed result. OneSpring has seen a related increase in the requests from clients to incorporate this type of technology into Web products, including consumer-facing e-commerce and marketing-related sites as well as back end or internal-facing systems and applications.

The interactive nature of the Web’s newest sites allows marketers to more fully integrate effective product messaging across the spectrum. There is good reason to do this, as estimates suggest that users who approach a product from a multi-channel perspective will spend 30 percent more over the course of a year (Reitsma, 2002). The message is simple: users who can find your product via multiple channels: the web, print, in-store, and television – are more likely to buy (BusinessWire, 2000).
Branding and marketing are becoming integrated across channels of product exposure. Elements that are featured in print campaigns can be featured on television campaigns, and the best of both of those campaigns can be featured on the Web, particularly if the website is delivering interactive content. When combined with other channels, the result is that the brand message becomes fully integrated into the user’s lifestyle. There is a downside to this, however. Studies estimate that users are bombarded by up to 5,000 marketing messages per day (Story, 2007). As the marketing message becomes more pervasive, users are becoming more adept at tuning it out, preferring instead to choose product information generated from other noncommercial sources, including social networks and rating sites. The proliferation of sites such as epinions.com and Amazon’s “rate this product” feature are two examples of how others’ opinions impact consumers’ buying decisions.

As a result, other differentiators are necessary to attract and retain users. As the stakes have grown, user experience has moved to the forefront of considerations to review during Web design efforts. Guidance given to marketers suggests that they pay attention to the usability of the sites that they are designing (Manning, 2000); however, OneSpring suggests that marketers take this a step further and consider their personas’ motivations and behavior, and to carefully craft the site around these needs. This is slightly different than the more generic usability advice given to most marketers. This information focuses on specific user scenarios or behaviors, and provides specific Web attributes to support these scenarios. OneSpring’s methodology incorporates this through discovery of user needs, a process that leads to the creation of use cases. By creating a website that accomplishes these use cases, a truly user centered/user-focused design results.

Don’t delay primary task satisfaction

Specifically, it is critical that the design of the site not compete with the user’s primary activities on the site. It is particularly important when applying dynamic content—including video and animation. Designers can often be caught up in the rush to place this content on sites because of the novelty factor or because this type of content is considered cutting edge. This content can be extremely distracting, however, presenting time delays in allowing the user to reach his desired goal. As a result, users become disenchanted and seek other avenues for product information – possibly leading them away from your product and into the arms of your competitor.

Other issues can arise. Technology—particularly that involving bandwidth or plug-ins—can prevent the user from reaching his goal. In a well-publicized study, researchers from Carlton University found that users can make snap decisions about the quality of a website—and whether or not to stay—in 50 milliseconds, which is roughly the duration of an eyeblink (Lindgaard, 2006). From a practical perspective, a site designer is fighting time the moment the user arrives on the site. By requiring the user to wait for load times, or by diverting his attention to download and install plug-ins provided by third party providers like Adobe or Microsoft, your opportunity can be lost.

Assuming the content loads and plays properly, it can still prevent the user from accomplishing his primary task. Generally speaking, users are in a very task-oriented mindset when they land on a site. Highly engaging content that does not match the users’ mindset will actually have the negative effect of drawing the user away from the task he wants to accomplish, or frustrating him because he perceives you are blocking his path. Because it is difficult to present highly engaging content for multiple tasks at the same time, designers should be aware that they run a risk of inadvertently changing the user’s focus on the site and possibly diverting the user’s efforts away from completing tasks she set out to accomplish. User dissatisfaction is the result. Only through careful understanding of primary user tasks, and matching the interactive content to match the most important task(s), can designers make sure that they do not cause this situation to occur.

Above all else, users want to maintain control of their browsing sessions. Abandonments on Flash-only pages are notoriously high, and Disney.com (Chris Chandler, personal communication, April 29, 2007) even removed its Flash- only intro after the corresponding “Skip Intro” link became the most-clicked-on link on the entire site. If the users can interact with your content in ways that suit them, they will use that content. If they cannot, or if they are forced into narrow patterns of use, they will abandon it.

How to make interactive content work for your users

OneSpring feels that interactive content should be used when it makes sense to support user tasks and enhance the user experience. Interactive content can provide a distinctly positive impact on the length of time that users are engaged on the site, repeat visits, and overall satisfaction with the experience. OneSpring does not recommend using interactive content simply because others in the competitive space are using it, because when used inappropriately, it can detract from the consumer’s success on the site and increase abandonments. Instead, we encourage designers to take the extra step in ensuring that their interactive content meets the consumer’s needs by completing the following steps, which represent OneSpring’s core offerings:
If the users can interact with your content in ways that suit them, they will use that content. If they cannot, or if they are forced into narrow patterns of use, they will abandon it.

1. Truly understand the user’s motivations for using the site and needs that should be addressed by the site through research activities that include interviews, observations, and/or surveys. Seek to understand the user’s context of use, e.g. the amount of time that they have available, or the number of potential distractions that are likely to occur while they are using the site.

2. Clearly translate the results of these research activities into sound use cases.

3. Prioritize these use cases to ensure that those activities that are most important to the user are realized first.

4. Carefully construct the entire user experience so that the primary (most important) tasks are addressed through the interactive content, rather than in spite of it.
5. Create a simulation of the proposed system
6. Share it with users to ensure that it satisfies their needs
7. Modify the simulation based on user feedback
8. Build the system, following the simulation’s example closely

The user should avoid designing a screen featuring only interactive or Flash-based content with a “Skip Intro” link and instead stretch their creative limits by providing multiple methods to accomplish each task. To accomplish an equally satisfying result with better user uptake, insert creative, dynamic elements that support the user’s needs. Blend dynamic content with text and links to give the users a choice of what to approach and how to approach it.

If designers are at all unsure of how a site’s userbase will respond to dynamic content, OneSpring recommends conducting a period of A/B testing that features dynamic and a nondynamic versions. By randomly serving each version for a reasonable period of time (e.g., one week), or by presenting each version back-to-back over two consecutive weeks, designers can analyze traffic logs to determine the relative impact of each design. While it may take additional time and resources to produce equivalent A/B options, improved user reception and conversions will likely mitigate or eliminate the expense later on. OneSpring has successfully used this with clients such as UPS, with a typical result being the selection of one screen over another, or the consolidation of multiple screens into a single, more efficient version.

By considering the user’s motivations for seeking information on products and remembering that they have the ultimate power to click away from your very expensive dynamic Web content, you will be able to create a successful, seamless marketing campaign that includes the Web as a channel for touching consumers. It is likely that their opinion of your brand will be enhanced and your ROI realized if you follow the steps above and masterfully create a Web experience that engages the users and supports their needs.

References
Business Wire. (2000). Jupiter: Multichannel Shoppers Buy More, but 76 Percent of Retailers Unable to Track Them Across Channels. http://findarticles.com/p/articles/mi_m0EIN/is_2000_August_29/ai_65823128/pg_2.
DeFelice. A. (2005). How Do Technology Buyers Conduct Research? http://www.destinationcrm.com/articles/default.asp?ArticleID=5468.
KnowledgeStorm. (2005). Eight Rules for Creating Great White Papers.

http://www.knowledgestorm.com/search/viewabstract/74728?c=hse

Lindgaard G., Fernandes G. J., Dudek C. & Brown J. (2006). Behav. Inf. Technol., 25. 115 – 126. Manning, R. (2000). Internet Branding and the User Experience.

http://www.clickz.com/showPage.html?page=822571

Reitsma, R. (2002). Retailers: Treasure Multichannel Consumers. http://www.forrester.com/ER/Research/Brief/Excerpt/0,1317,15004,00.html
Rogowski, R. (2006). Web Users Want Rich Internet Applications.

http://www.forrester.com/Research/Document/Excerpt/0,7211,40333,00.html

Story, Louise. (2007). Anywhere the Eye Can See, It’s Likely to See an Ad.
http://www.nytimes.com/2007/01/15/business/media/15everywhere.html?ex=1326517200&en=a405e6d0cb65c00a &ei=5088&partner=rssnyt&emc=rss.

How Visualization is Changing the IT landscape

The requirements definition phase is a relatively small but extremely important area of the software development life cycle. Although a majority of software budgets go to the actual development side of the house, the overall cost of a project over the long run is directly related to the quality and accuracy of the requirements fed into the project. Most companies waste valuable time and resources defining inconsistent and inaccurate textual requirements, which for the most part the business and development don’t read. The issue that more and more companies are starting to see is that faulty requirement upfront can lead to time-consuming issues and defects during the development phase of a project.

On average, companies allocate 25% of there project budgets to rework alone.

70% of software or Internet-based application projects fail or never get implemented the way they were intended. In fact, 25-40 cents out of every dollar spent on software development is wasted – because the business requirements were not defined right in the first place. Experts agree the root cause of this problem is that stakeholders often don’t know or can’t express what they want, and current methods and products for eliciting requirements simply aren’t bridging the gap. They simply don’t provide a way for the business to effectively discover and communicate their needs – until it is too late.

Visualization provides the ability for stakeholders to not only “see” their business requirements, but to experience them as well – before it is built. The goal of visualization is to reduce project costs and to decrease time-to-market by better improving collaboration between a business idea and the implementation of that idea. This is the biggest issue within the software development industry today. Visualization the gap between requirements and development. It also allows companies to experience real world applications in weeks, rather than months.

The Art of Integration

Visualization is a way for businesses to see and experience their IT project before any coding is done.

Choosing the right visualization product to integrate into your existing methodology is very important. Key factors to consider when choosing a simulation product are:

• Will the visual representation produced by the simulation product mirror the actual look and feel of the application?
• Will the simulation product incorporate business logic into the look and feel to illustrate the actual user experience of the final application?

Integrating a Simulation product will allow business users and developers to interact with the product before development actually begins. Products exist that allow a Business Analyst to create a Web application complete with functionality in a short timeframe. Web-based tools give business units the ability to share and review the various iterations of the application easily over the Internet.

With all of these features considered, the actual integration of the product becomes easy. Where traditional projects must dedicate substantial time and cost to initiating change requests and working out development issues after the fact, simulation allows your team to deal with these issues as the process is evolving.

Effective simulation products utilize an iterative approach, ensuring that products will be completed on budget, on time and with the approval and complete understanding of the end users. Integrating simulation into your existing methodology is easy with the right product and will give your developers a clear understanding of what to build and will reduce the likelihood of costly changes that will delay your project.

Which Tool is Right for You?

You want to build your business applications right the first time. Software development projects are inherently complex and require meticulous planning. Research shows that 70% of software development projects fail for a variety of reasons. At the top of the list is the improper capturing of requirements. This doesn’t have to be the case.

A visualization that mirrors the look and feel as well as the actual functionality of the end product is critical. Involving the business units, end users and developers into the process is equally critical and the simulation tool you select must give you the flexibility to manage the iterative process.

The following benefits should be considered when selecting the right simulation tool for your business:

• Save money by reducing the number of changes to the final product
• Deliver a product that is fully understood and adopted by all business units
• Uncover missing requirements before development begins
• Shorten the length development time
• Estimate the cost of projects more accurately

Visualization products like iRise allow your stakeholders to iterate without disrupting developers productivity. When IT departments are clear about what to actually build, costs are cut, productivity is increased and opportunities are more easily realized with the benefit of saving time and cost.

Finding the right simulation product will reduce development time and allow you to reach the market sooner. Your company will benefit by delivering applications that meet the needs of your business and are readily adopted by users.