In her Escaping Navigation Hell presentation at the Web App Masters Tour in San Diego, CA, Hagan Rivers outlined her use of application maps to get a 30,000 foot view of a Web application. Essentially, application maps are diagrams that illustrate the types of screens in an application and how they are related.

What I found most compelling about these diagrams is that they illuminate the core areas of focus within applications quite clearly. In fact, looking at various application maps you can really see key differences right away. Consider the application maps for:

In Hagan’s own words:

“Why do I make these maps? When I look at an application I look for it’s hubs. The hubs are the work areas – the place where the user creates things and does things to them. In complex applications (one with hundreds of screens, for example) there may be dozens of hubs and their relationships may be complicated. I use the Application Map to help me visualize these applications more clearly and to act as a foundation for the design of the navigation system.”

In you are interested in how these application maps are made check out the video by Hagan below or come to the Web App Masters Tour and get the inside scoop from Hagan herself. If you’re thinking about going you can use the promotion code LUKE when you sign up and save $100.

Overview

Below are the answers to a few questions about the difference between SaaS application design and application design.

Key principals SaaS design

• By relying on common web patterns, SaaS designs have more of a “walk up and use” quality which drive most of the design decisions.
• As is typical with most software, SaaS applications release with a core set of services, then add feature to those services or add entirely new services.
• SaaS interactions tend to be narrower and shallow, i.e. the On Demand user drills ‘into’ and ‘out of’ an object and associated content appears as part of this ‘linear’ interaction.
• SaaS can sell every ‘aspect’ of the solution, e.g. IOD is selling ‘services’ and the ‘number of connections’
• SaaS marketing tends to pitch ‘services’ or ‘platform’ offerings
• The SaaS designer may focus on the design of a particular ‘service’ or addition to the ‘service’ for a shorter time period than with thick application design. The designer, however, should also focus on the application’s long term goal, e.g. IOD’s long term goal to become a platform. Therefore, IOD has specific long term platform design goals that should be taken into account when early application activities are planned and executed now.

General Questions

In what ways does the design process of a traditional application/tool need to vary for a SaaS application?

Despite the typical issues and the extreme speed at which the product is developed, the same user centered design process should be used, however, the designer should:

• selectively focus Ux resources on select issues / features
• create a more definitive process timeline where studies are planned either 6, 9, and 12 months in advance
• focus on only one to three design proposals for a cycle.

The reasoning behind this approach is because any more than a few designs will not make it into the development cycle and / or will be de-prioritized for the next release.

Specifically, Informatica On Demand’s four-month delivery timeline causes features to be promoted in and demoted out of the product overnight due to some or all of the following:

• time to build constraints,
• lack of Development resources,
• lack of feature definition,
• lack of design time,
• lack of customer need definition i.e. is this the feature the customer real expects for this release

How should the designer “think” about designing SaaS?

Four things that effect design:

• user’s proficiency / expertise, needs, and expectations
• development resources, cycle, and time to market
• designer’s materials and process
• timeline

The speed at which decision-making and design need to occur should not effect how the designer approaches a design. However, due to the time limitation, I will say, the designer (I) depends more on anecdotal evidence when working on SaaS products.

Is the real factor with SaaS the fact that one is continuously rolling out new and updated features every 4 months?

The continuous feature design and update every 4 months does not really affect the way a designer’s thinking because the product’s design is considered in its ‘entirety’.

With IOD, there was an initial product definition and user experience design then Development builds the core product. Once that core product had been built, the other elements previously defined and designed are built by Development in an ongoing process. At this point, the designer’s roll becomes more of a ‘design shepherd’ because they find themselves

· checking the quality of the previous build,

· modifying the existing design to mimic the elements Development were able to build due to technical limitations, and

· filing bugs against the elements Development created in a vacuum.

How does that fact affect a designer’s ability to plan and contribute?

Unlike other types of conventional applications and tool applications, where timelines allow time to ‘sell a design direction’ up and down the ladder. Rolling features out every four months forces the designer to work lockstep with the user experience development team to create an extremely strong and trusting relationship. And it is this 4-month cycle that makes the synchronization tighter.

Moreover, because the designer is so involved with the Development group, more design problems are presented to the designer, therefore, they are able to implement more consist solutions.

Unfortunately, the ability to plan is more complex because the question becomes ‘do I (the designer) work on known problems OR do I try to find and resolve possible issues?’ Therefore, opting for working on ‘known problems’ relegates research and studies to a secondary position.

Specific application questions

Service(s) versus product feature(s)?

Designing for a ‘service’ versus a ‘product feature’ is different in that interaction and visual design are tighter. ‘Services’ and ‘product features’ appear as a family, however, the designer has more latitude when creating interactions and experiences for a product’s feature. Services require more consistency between experiences and interactions, especially if they are self serve.

Functionality breakdown?

When looking at the ETL possibilities, the IOD product management team extracted the most basic functionality and tried to create parity. IOD ‘services’ tend to be discrete components in a suite of products, i.e. the ‘service’ is designed and developed as a whole solution. Moreover, other elements may be added to enrich the interaction or the service but the service can stand alone without the ‘enrichment’.

Selling service(s) versus product feature(s)?

There is only a slight difference between selling services versus product features. When selling SaaS services, almost every aspect can be sold separately. When selling product features, they are typically sold as a whole package with limited breakdown.

Specific application technical questions

Zero install (and its implications)?

Zero install is a misnomer because 1) there is always, as I understand it, an ‘agent’ that connects the user’s computer to the vendor, and 2) by general definition ‘zero install’ implies that the computational processing happens on the server. Neither of these points are the case with SaaS applications.

Professionals using SaaS application have stated that they expect a download for communication with the ‘service.’ However, the download user experience is crucial because any of the following can cause a user to be dissuaded by the product:

• lack of information surrounding where the application is installed,
• not knowing what exactly it is doing,
• not knowing how to interact with the agent outside of the application (e.g. restart the agent),

Again, lag time or missing information surrounding any of the items listed lead to confusion for first time users during testing and me as a proficient novice user. Moreover, company firewall settings and data (server) access are huge issues for SaaS applications that are being used by people in passing or those who are acting ‘under the radar’

Fewer objects to manage?

Not all SaaS applications use fewer objects or have fewer features than other applications. I believe some of these applications have fewer objects and features to increase ‘walkup usability.’

Specific design related questions

Faster iterations?

The cycle times impact the designer and the design because the cycles are shorter, more condensed. This forces the designer to push for closure on design, design decisions, scheduling, be extremely flexible, and track all decisions energetically.

Quarterly releases?

IOD releases every three to five months.

Incremental functionality?

IOD has delivered complete user facing core services with additional features added in subsequent releases. However, this is typical to most products I have worked on thus far, i.e. release with a core set of features, then add functionality to those feature and broaden the core.

As a designer entering at the end of the core definition, it was important to become extremely familiar with all interactions and Development’s reasoning behind each feature. These interactions and reasons shaped future designs because users have set their expectations on how the application is going to work based on their prior experience. In essence, the designer is almost forced to select from previously created interactions for their new designs. While it is ultimately the designer’s decision to design the best experience, the previously created interactions and Development’s reasoning also drive the various designs.

User feedback?

User feedback for some SaaS is very direct (email link, support link) and is placed prominently in the application space.

For IOD, Help and Feedback links are placed in the upper right hand corner – a common web pattern. The placement of Help in this common and highly visible location offers users assurance through commonality. Moreover, as with other applications, the Solution Managers and Product Managers collect user feedback directly from customers.

Guided tasks versus unstructured tasks?

For Informatica Cloud products, we should offer beginner (wizard assisted) and expert (unaided) modes, if possible. If this is not possible, the designer should adhere to this common practice and offer a guided experience through the most basic creation tasks and access to the more advanced elements during viewing and editing objects.

How to manage large sets of objects?

In Cloud, we provide filtering options for large data sets.

Interaction styles?

Even today, IOD’s development team is focused on stability and new features using the existing technology. The IOD’s web-based interactions are ‘simplistic / crude’ by comparison to the desktop’s interactions. With the Informatica On Demand tool being browser based, this places another level of difficulty on any design activities because the interaction needs to be common to the web 1.0 browser’s user experience for the most part.

Of course, richer interactions are available via various widget toolkits. However, there are issues with each of the widget toolkit options, e.g. proprietary language.

One final thought…SaaS interactions tend to be narrower and shallow, i.e. the On Demand user drills ‘into’ and ‘out of’ an object and associated content appears as part of this ‘linear’ interaction. By comparison, interactions associated with applications can be broad and deep. Understanding this design decision / philosophy will help the designer understand users’ expectations that come from commonality and legacy.

Group ‘psychological makeup’

Team psychology?

One of the things I have noticed from Siebel On Demand (an application) and Informatica On Demand (a tool) is that the team has a team mentality – one for all and all for one. Of course, each individual takes ownership and pride in their section of work and they all tend to pull together to accomplish the delivery.

Moreover, on either of those teams there was very little in fighting or back biting within the team based on what I saw working with development, marketing, product management, quality assurance, and solution management.

Sales team psychology?

SaaS Sales teams are working for smaller deal sizes. The IOD Sales team are working and closing deals in days or weeks as opposed to months or years.

This allows the Sales team to have more contact with more customers which create more datum points from which to form opinions about what is needed in the product. Ultimately, this drives the solution manager and their decision process to pick which features go into the product and may drive the designer to gather information about these requests during interviews and testing.

Dev team psychology?

Based on the shortened timelines, the Dev team tends to be more direct and decisive. As with all products, Dev can decide to make the final call on some items ‘to make the delivery date.’ Ultimately, this effects which features are selected from the design.

Moreover, understanding how the Cloud Development team was going to react to the introduction of new user interface interactions, let alone new interface elements that would require new technology, has caused me to be more cautious in my design proposals and opt for existing interactions rather than introduce a new interaction unless it was truly necessary.

Influencing the team?

The same psychological influences are at play when designing for SaaS and applications. The designer still needs to be ahead of the curve and sell their designs and ideas to the broader team.

Specifically, to get ahead of the IOD curve, the designer should:

• be well versed with the existing design
• the design’s history
• and the team
• understand the product’s “perceived problems” from the customer and the team perspective
• perform usability tests and field research to understand the actual problems
• pick a few of the key problems to develop a concept with anecdotal evidence and sell it to the senior executives like Ron Papas, Krishnan, and Ron Lunasin

]]> http://rsloandesign.com/experiences/2010/02/design-experiences-qa-saas-applications/feed/ 0 http://rsloandesign.com/experiences/2010/02/remove-contribute-cs3-toolbar-in-ms-office-macromedia-contribute-general-discussion/ http://rsloandesign.com/experiences/2010/02/remove-contribute-cs3-toolbar-in-ms-office-macromedia-contribute-general-discussion/#comments Thu, 04 Feb 2010 06:02:03 +0000 R Sloan Design http://rsloandesign.com/experiences/?p=394 via Remove Contribute CS3 toolbar in MS Office? – Macromedia Contribute General Discussion.

To remove the Contribute plug ins – you will need to close both Contribute and MS Office applications. Then navigate to C:\Program Files\Adobe\Adobe Contribute CS3 and rename the following file from officeplugin.dll to officeplugin.dllOLD. When you relaunch Word, Excel or Outlook – the Contribute toolbar should be removed.

If you choose to add the toolbar again in the future, you just need to remove the OLD from the file name. Then bring up the command.exe window and browse to the program’s directory C:\Program Files\Adobe\Adobe Contribute CS3\ and then run the following command: regsvr32 officeplugin.dll

This will re-register the .dll file responsible for the toolbar.