The best successful strategy for fostering ‘buy-in’ from other departments depends on your particular situation and the nature of any resistance you encounter, here are some ideas to help you get started.

• Run a pilot project and try to engage some of the stakeholders from other departments in persona development activities. Engage them in the planning process, work-shopping personas, or involve them in the persona review process. If they understand how the personas were arrived at (and even better if they were involved in creating the personas) they will be more likely to ‘buy-in’ for this project and future projects.
• You could also try to evangelize or share persona success stories from other projects or other companies. Forrester Research has gathered some great data on the ROI of personas.

You’ll find our whitepaper: How Personas Drive Design of Successful Business Applications informational for departments who may be new to the concept of personas.

Related blog posts:

Why User Research & Personas are Critical When Developing Business Apps

Benefits of Using Personas and User Profiles Together

Creating a Culture of Customer Centricity

A user profile provides a summary describing a collection of users. Since the profile is meant to include all the users within the group, the details in the profile generally describe ranges or frequencies of responses.

This quantitative picture of a group of users can be valuable for identifying design and development priorities, and is often a good starting point for user analysis. However, the quantitative profile can have some limitations. Averages and ranges don’t always give a complete or accurate picture. For instance, learning that a collection of 100 users has an average age of 35 may lead to different decisions than knowing  that 50 users were age 20 and 50 users were age 50. Plus, the segmentation produced by profiling may result in a large set of user profiles, and statistics can sometimes be impersonal and hard to remember.

Despite their differences, profiles and personas work well together.  While a user profile provides a composite summary of a group of users, a persona describes a representative (but fictional) individual. Rather than describing ranges for the entire group (e.g., ages 20-50), a persona has specific details (e.g., age 22) that accurately reflect and highlight important features of the group. The profiles can provide input to the personas, and the process of creating personas and the nature of personas themselves can address many of the limitations of user profiles.

The process of creating personas should include analysis of the user profiles, including identification of important clusters of users within or between user profiles. Ideally, this analysis and prioritization will produce a small and manageable set of personas, since there does not have to be a 1-to-1 correspondence between personas and user profiles. Plus, the persona itself should be written in a way that will encourage readers to recall the persona and use the detail to enhance the design and make informed choices.

So while personas and profiles may be based off the same user research, they provide different, but complementary views of your users. Also, the process of compiling profiles, then analyzing the profiles in order to create a targeted set of personas is a great alignment exercise, and the output (the personas themselves) provides an accessible and easy to remember description of key users, including their attributes, needs and priorities.

In contrast to retail behavior patterns, business users spend many hours of their workday using a core set of transactional applications. Some of these are provided by their own company and others compete for attention in a competitive marketplace. The user interface of these applications either enhances or inhibits user productivity and loyalty – often directly impacting the revenues generated by these tools. Therefore it is just as important to understand users and develop personas for business applications.

To be effective, persona development must be firmly grounded in user research techniques such as contextual inquiry, user segmentation and profiling, and prioritized task mapping. Strictly speaking, a persona is a narrative description of a user who represents an important segment of the user population. These narrative descriptions, however, only hold value for project teams if they are the culmination and thoughtful synthesis of many sources of information about the user population. This process begins with user interviews. The interview process may start with working assumptions about how the user population can be segmented, but nothing replaces the insights that will be gained by interviewing users in their normal working environments while they are using the application. Insights gained from these interviews allows you to identify and validate meaningful segments in the user population and document the most important user profiles. User profiles are the foundation layer beneath well constructed personas. The two concepts may seem like they overlap, but a good way to understand the difference is to keep in mind that user profiles describe “types” of users while personas describe specific people. User profiles have attributes like: “80% Male”. In contrast, personas are given names like ‘Mike’ and have characteristics like: “34 year old investor who has recently quit his job to become a full time day trader.”

My next post will examine the progression from user profiles to personas, and how to use personas for success business application development. Stay tuned.

1. Factor time and resources for the prototype into the project plan.
   Developing a prototype will add time for both developers and designers, and the project plan should allocate the necessary resources and include these costs. Plan for an iterative approach of designer feedback and developer revision. Doing so can help quickly determine the availability of proper prototyping resources. The phases of the project may need to be delayed in order to obtain the appropriate resources.

2. Incorporate end-user prototype testing, validation and quality assurance as key milestones in the project plan.
   Of all the tasks in the project plan, the areas that are cut when time becomes an issue are quality assurance and end-user testing. Allowing adequate time to prepare and design a prototype as well as setting up end-user testing is vital to the quality of the site or application. Make sure they are key milestones in the project plan that require validation in order to pass versus simply adding the tasks as additional “scope” in the project.

• jQuery – A popular JavaScript framework that provides rich support for creating client side browser applications.
• YUI – Another popular JavaScript framework, Yahoo UI Library is a high-performance and flexible framework used in highly interactive sites such as the Yahoo homepage and Yahoo mail.
• AUI – Alloy UI is an emerging framework from Liferay that enhances YUI. It provides an additional library of user interface components built on top of YUI and provided with Liferay out-of-the-box.
• GWT – Google Web Toolkit is a rich JavaScript client library that powers sites such as Google Mail and Google Maps.
• Vaadin – A Java server-side client framework, Vaadin provides user interface objects using a component model, similar to how Java AWT or Swing works.
• Others: (ext-js, dojo, etc)

The RIA flavor you choose to develop your application is an important decision, but it is equally important to consider how the selected portal platform supports and integrates with the chosen RIA technology.  Because the RIA framework is an integral part of the portlets you develop, it is important that the framework is provided from a foundational level of the portal.  In other words, the application needs to be viewed systemically rather than looking at individual portlets, especially from a performance standpoint. This becomes more critical if your application needs to scale.

Portlets are designed to be self-contained, with all of their supporting resources meant to be included. When developing an entire application however, looking at the portlets as a system can result in positive performance outcomes. Consider three portlets that utilize jQuery for their user interactions.  These three portlets would normally include the jQuery JavaScript libraries individually. If all three of them are placed on the same page, the libraries will be downloaded three separate times. This design will have serious performance implications. A good portal platform will make it easy to coalesce the portlets into a single library, while providing the ability for it to be cached.

When looking at the portal systemically, four good questions to ask include:

1. Does the portal platform provide the ability to combine all the RIA libraries into a single resource to minimize the HTTP requests needed for a single page?
2. Is the portal platform smart enough to combine requests across portlets using the same resources into a single resource request, rather than making individual requests?
3. Does the portal platform provide the ability to minify JavaScript resources served in order to decrease the payload size of the served resources?
4. Does the portal platform provide the ability to cache the resource requests on the server side and eliminate re-serving those resources by using a server response such as HTTP 304?

Liferay Enterprise Portal supports all of these requirements.

The Liferay portal platform fully supports the use and configuration of gadgets to provide mash-up capabilities that ultimately benefit your applications’ users.

1. Strategy. A company needs to carefully focus on the highest value usage scenarios while thinking through the mobile touch points within context of the entire ‘day in the life’—not just specific workflows of a customer. Also, consider how other digital touch points tie in. Be sure your mobile strategy can evolve over time.

2. Timeline. Customers typically want to ideate, design, develop and launch more quickly than on traditional portal or application initiatives. This can be a real challenge if there is no current framework for working in a more agile way and if the company doesn’t have prior experience or infrastructure in place for mobile development. Create a methodology that allows for a rapid ideation and design process on the front end to jump start these initiatives. Then, work carefully to define a very focused and feasible scope that can be rapidly developed. Set the model for future enhancements post launch.

3. Multi-Device Considerations. With mobile there are nuances around the device and platform that need to be thought through carefully as well as whether the application should be native or web-based. The emergence of HTML5 will help to simplify these issues by providing a flexible, rich interface solution where historically there have been considerable hurdles. Understand the pros and cons of each and select the method best suited for your mobile needs.

A native CMS within a portal platform should minimally support the ability to:

• Import content from existing repositories into its own repository. (E.g.,  via import utilities that programmatically
  use an API)
• Manage and edit unstructured HTML content using a modern WYSIWYG editing interface
• Define and use workflows that are based on the jBPM standard
• Define and use structured content types. The CMS should provide:
• The ability to define new structured content types without having to restart the server
• The ability to create display templates for the structured content types
• An easy to use interface for editing the structured content types
• Preview content and publish it to staging and production environments
• Automatically create versions when changes are made
• Support automatic expiration of content based on a date attribute.

The Liferay portal platform provides strong CMS capabilities, and was recently named the most popular Java-based CMS system in Water & Stone’s 2010 Open Source CMS Market Share Report.

As mentioned above, good portal platforms can also easily integrate with externally managed content. Since moving a significant amount of content from an existing CMS can be cost prohibitive, it makes more sense to manage, access, and serve the content directly from the external CMS. Ideally, the portal platform will support the external system through a native interface protocol. Alternatively, external content should be able to be accessed using the standard Content Management Interoperability Services (CMIS) protocol.

Liferay Enterprise Portal is an example of a platform that provides out-of-the-box connectivity using native protocols for integration with SharePoint and WebDAV- based repositories.  Other repositories, such as Alfresco, are supported directly using the CMIS protocol. (Earlier versions of Liferay simply used Alfresco as a repository with the intent of using the native Liferay user interface to manage content.  However, the latest release supports bi-directional editing capabilities where the same repository hierarchy is reflected in both platforms, making it easy to edit the content from within either environment.)

For more info, check out our white paper: Is Liferay Right for Your Organization.

1. Bringing the user interface design to life.
   While end users can view and comment on a paper-based version of an application, they will not be able to fully understand the nature of key interactions until the application is developed. Creating a clickable prototype is the next logical step in design and brings a design to life.
2. Allowing users to provide valuable feedback within the proper context.  
   By using a prototype, data within the context of the entire application demonstrates scenarios in a form that users can understand. Since users see the appearance of a working application their feedback will be almost as valuable as having the fully-functional application. 
3. Helping reduce overall development time.
   When prototype development is not part of the process, design changes found during development can affect code. Recoding an application during the development phase can take a great deal more time and effort and significantly impact the development schedule. In addition, recoding an application due to post production usability issues can be costly. Making multiple changes to a prototype is much simpler and provides timely user feedback—keeping the focus on coding the site/application versus worrying about rework due to pre- and post-production usability issues.
4. Acting as a useful reference tool for developers.
   Prototypes can be used to illustrate functionality in a way that screen specifications cannot. For example, if developers need to understand how a specific widget or control is intended to work, they can use the prototype to answer functionality questions.  
5. Confirming a common vision among users and stakeholders.
   A prototype allows key stakeholders within the organization an opportunity to see the application design as it was intended to be used, including buttons and interactions working in a manner that is as close to the final product as possible. Most key stakeholders are not designers or developers. They are end users of applications and are used to seeing an application in its working state. When static, non-interactive prototypes are delivered to these key decision makers, more time is spent discussing and describing how a particular feature is going to work and less time on understanding the overall design. When key stakeholders have the ability to interact with the final application design, the buy in process and ongoing support is usually stronger.
6. Creating excitement within the organization
   Prototypes can also be used as a powerful tool to communicate positive progress and reveal the next tangible step towards producing the application, creating excitement within the organization.

Many UX teams work without integrated UX toolsets and collaboration environments like developers did 10 years ago. They work as artisans to deliver user experience without being truly supported by a business culture dedicated to customer centricity.

We’ve worked with a wide range of these teams, and it’s remarkable how dedicated and under-served they are. Inevitably our work becomes a showcase to demonstrate the value of doing customer experience work ‘the right way’. The positive business outcomes from these efforts help the team gain visibility with their business decision makers, with the hope being that ‘user-centered design’ will stick and gain more support. The good news is that a lift is coming from outside now—the trend of customer centricity has swung to the mainstream.

If the mandate has already been handed down in your organization, the question becomes: what does it take to create a culture of customer centricity? How does an enterprise move from a place where the knowledge of the customer is either in the hands of a few, based on opinion, or completely lacking–to a place where the customer perspective is data-driven and shared?

A key ingredient is creating a sustainable culture that embraces user research and persona modeling. For those of us who do UX work for a living, this is second nature to us. We know how ethnographic research uncovers the right depth of insight into our users —the things that drive behavior, conversion, adoption, productivity and satisfaction. We’ve found that when we deliver rich personas early in our client work it invariably has a huge impact across the organization. Making personas visible and collaborative across the enterprise begins the critical exchange required in a culture of customer centricity.