User scenarios | why & how

Designing Vennster.nl | part 3

In my last 2 blogs I explained that in the life cycle of experiencing the services/products of your company, users of your website can be visitors, customers or relations.

I also explained the importance of knowing the needs, wishes, knowledge level and habits of the users of your website and how to personalize this information by creating personas.

In this blog I will explain how stories of how a persona interacts with a website/application (scenario), puts the persona in motion and how this helps you to design a website in which the navigation steps are obvious to a user.

Writing scenarios

Scenarios put personas in motion. Scenarios are stories of how a persona interacts with a website/application. The persona is the character, a scenario is the plot. I wrote scenarios for each persona visiting the Vennster website-to-be.

In the scenarios I described:

• The most important situation in which the future users of the Vennster website,  Afra, Bernice or Carl would use Vennster.nl – I set the scene
• What Afra, Bernice or Carl want to achieve while visiting our website
• Which steps they would take including their thoughts and considerations at each step
• What feedback or guidance they expect from the website.

Underneath 2 parts of a scenario I wrote for Carl – the persona representing the Vennster relation.

The benefits of scenarios

 

• By writing down in a scenario what a persona wants and expects from your website/application what he thinks, assumes and how he acts, you create:
• A story which makes the persona come to live for all people involved in the design/development process of the website/application. – This helps them to reason from the user context instead of their own context
• An indication of the navigation structure: the user takes steps in a certain sequence to achieve his goal – make sure the website/application supports this.
• Ideas for new functionality which is needed by the user; he wants to accomplish something - the application should provide him the means for this.
• Recognition and acknowledgement from users. When confronting them with the right scenarios you will receive remarks like: “Yes I see…, this is what I meant, I only couldn’t find the right words for it myself.” You actually help users to formulate or order thoughts they sometimes even aren’t aware of.

• Scenarios also include what can go wrong by describing typical problems that occur and how the characters in the scenario solve these problems.
• Scenarios contain information about what feedback a user expects at which moment when using the website/application. Make sure you supply them with this feedback.

Personas give you an indication of who the users are. User scenarios provide information on how users will be interacting with the website/application you intent to design.  Therefore personas as well as scenarios are crucial to be able to develop a website/application for visitors/users to achieve what they really want/need.

N.B. The scenarios describe the most probable cases that the user will need and that you want to support. Keep them in mind when designing and developing your website or application. However, as Alan Coopers states in one of his design axioms:  “Design for the probable; provide for the possible.”  In other words, the use of scenarios shouldn't result in a restricted user interface. It should result in a structure that is optimized for the most probable usage scenarios. The more exotic or less frequent scenarios should obviously still be possible and accessible. Think for example about changing your personal data on an e-commerce site. This is less important than the ordering of products, but you still make it possible for users to execute this task.

With the personas and scenarios for Vennster.nl, I gathered crucial content for the User eXperience Design Quadrants model (XDQ copyright 2009 by Akendi) which I use as a guideline to great UX-design.

In my next blog I will tell you more about the XDQ-model and how I use it while defining the UX for Vennster.nl 

Personas | what, why & how

Designing Vennster.nl | part 2 

In my last blog I explained that in the lifecycle of experiencing the services/products of your company, users of your website can be visitors, customers or relations.

In every phase of the lifecycle, a user has different needs regarding the website.

To be able to create a successful, user-friendly website or application, every decision you take, whether you are part of the marketing team, the design team or the development team, should be based on what you know about the user.

But be aware of the fact that YOU are NOT the users/visitors of your website/ application.

For example:

A manager is looking at an application which is designed to be used by the customer service department within his company. He judges it and says: “I don’t understand this button!” He himself will never use the tool. His service people are working with the tool every day, therefore they have different expectations and requirements than their chief executive. For them this criticized shortcut key is one of the features they like most about the application, saving them time in processing the calls.

It is important to realize that:

• Your visitors have different goals than you have.
• Users/visitors don’t care about the way the product is created as you do. They have no interest in how the carefully crafted navigation system that you are selling them works, as long as they can accomplish their goals.
• User/visitors have different skills, background, education and interests.

As you can see from this, you are not the (target) visitor of the application or the website, and… the users/visitors of your website aren’t all alike!

Creating a realistic character sketch which represents one or more segments of the website’s or applications target audience (a persona) helps you visualizing the user(s) of your website. This then helps you focus your effort on certain personas and aides in your decision-making during planning, design and realization.

Creating personas

During my search for user needs, - characteristics and their behavior regarding our own website I learned about them through direct contact. For example by doing user research like: 

• User interviews and field studies; 
• User surveys.

If you don’t have the opportunity to meet your user(s), doing desk research can also provide you with the necessary information to collect information about users.

I came to know about the goals, the behavior and the attitude of the different users and found information about their background and knowledge level regarding the website we want to design and develop.

With the information I gathered from the research, I was able to create 3 realistic character sketches (personas) which represent the different users of our Vennster website.

Personas put a face on all the user research. Each persona has a name and a face (by means of a photo), a profile and a quote from the persona that captures his/her essence and serves as one of the initial things to get a quick sense of that persona. A persona also includes personal information, domain specific information, and information about his or her computer and internet usage.  In addition to all this information it’s key to also add the business objectives you have for the persona.

For Vennster.nl I created 3 personas:

• the visitor (Afra - Looking for Vennsters experience);
• the customer (Bernice - Satisfied with the Vennster consultant);
• the relation (Carl – How can Vennster and my company cooperate?).

Underneath for example part of the description of Carl - the persona representing the Vennster relation.

Besides the information about the characteristics and an indication of their lifestyle and identity, the description of what motivates them, their experience with computers, internet and which websites they prefer helps to give the character more depth in areas that are relevant for our website. 

Prioritizing personas

Sometimes you find personas have conflicting needs with regards to the website. In our case the technical persona (Carl) knows the jargon but the business user (Afra) is not familiar with the technical terms. A way of dealing with that conflict is to prioritize the personas.

Together with Vennsters management I figured out which persona is the most important to satisfy by deciding which one is the most (financially) valuable to Vennster as a company.  This primary persona is the one for whom we will optimize the site.

Furthermore we as Vennster decided what we will do with the needs of the other personas. Possible solutions are micro sites, a blog for the more technical user, etc. 

The benefits of personas

As this example shows, personas have the following benefits:

• Personas bring focus.
• Personas build empathy, not only because of the fact that they have a face and a name, but also because it is as if you really know them personally.
• Personas encourage consensus. They bring the marketing-, design-, development team together and create one shared vision of exactly whom the team is designing for and what the users want:
• Business development; developing a strategy that fits the client.
• Marketing; seducing the user/visitor.
• Technical development;  developing with the user in mind.

• Personas create efficiency. They help the whole team to decide what to create in the first place.
• Personas lead to better decisions; every decision the team makes can be linked to users in a defensible way.

Source of information: 'The User Is Always Right' by S.Mulder with Z.Yaar.

Above mentioned benefits indicate the role of personas in the UX design process. Using personas ensures that marketers, copywriters, designers and developers during the development of the site do not lose sight of the users/visitors when taking crucial decisions.

In my next blog I will tell you more on how to put personas in motion by making them the main characters in user scenarios - stories of how a persona interacts with Vennster.nl - and why doing this helps you design and develop a usable website/application.

 

Article published | Securing Heterogeneous Systems

Oracle Technology Network (OTN) published the article Securing Heterogeneous Systems Using Oracle Web Services Manager by Ronald van Luttikhuizen and Jens Peters.

The article is a case study on using Oracle Web Services Manager to secure interactions between Web Services exposed by Oracle Service Bus and an employee portal built in Microsoft .NET and Silverlight.

More sources

• Security and Administrator's Guide for Web Services, Oracle Technology Network
• Interoperability Guide for Oracle Web Services Manager, Oracle Technology Network
• Securing Oracle WebLogic Server, Oracle Technology Network
• Silverlight homepage
• Networking and Web Services in Silverlight, Microsoft MSDN Library
• How to: Use Message Credentials to Secure a Service for Silverlight Applications, Microsoft MSDN Library
• Security Guides, Oracle Technology Network
• How to: Create a New Silverlight Project, Microsoft MSDN Library
• How to: Add, Update, or Remove a Service Reference, Microsoft MSDN Library

About the authors

Ronald van Luttikhuizen is Managing Partner and Architect with Vennster and an Oracle ACE Director
Jens Peters is a Technical Architect with One Fox, a Microsoft Certified Gold Partner

Live Fusion Middleware Development Session @ OBUG Connect 2012

The MECC in Maastricht will host the 5th edition of the OBUG (Oracle Benelux User Group) Connect conference on tuesday the 24th of April. This conference will be the third time that a group of Fusion Middleware specialists from different companies such as AMIS Services, Vennster, Veriton, and Oracle Consulting Services team up to present a live application development session after successful performances at ODTUG Kaleidoscope 2011 and UKOUG 2011. The goal for these events is to build and demo a working application in just half a day using JDeveloper, ADF, Oracle Service Bus, Oracle SOA Suite, and Oracle BPM Studio. At the upcoming OBUG Connect 2012 conference the team will consist of Steven Davelaar, Lucas Jellema, Edwin Biemond, Luc Bors, Lonneke Dikmans, and Ronald van Luttikhuizen.

Attendees can walk in and out of the session, ask questions, interact and comment on the way developers build the application, and see how Fusion Middleware can be used to build an application based on SOA and BPM principles in a productive and iterative way. Thanks to Murphy and his law, at each development session unexpected things happen that need to be dealt with by the development team and session moderators in a short time frame. So come and see!

FMW development session at UKOUG 2011

Read more about the OBUG Benelux Connect 2012 program here.

Enterprise Manager showing use of custom fault handler

In a recent project I explained the fault handling mechanism used in our Oracle SOA Suite 11g composites to a new team member. That particular project used a custom fault handler as part of the overall fault handling strategy. Custom fault handlers are "hooks" in SOA Suite 11g that you can use to plugin your own fault-handling code. In some situations this can be useful as substitute or addition to the fault handlers that are provided out-of-the-box such as retry and human intervention.

The new team member wanted to know whether faults were handled by the default actions provided by Oracle SOA Suite, or handed over to the custom Java class that implemented the custom fault handler. Besides including logging in the custom fault handler Java class itself you can also use the Enterprise Manager.

In Enterprise Manager you can inspect what fault handlers are executed, including the custom handlers (and their implementation class) which improves traceability. The figure below shows the instance trail of an errored process instance for which the SOA Suite has invoked a customer fault handler com.odtug.soa.tooling.FaultHandlerJavaAction. (This image was taken from my fault handling presentation at Kaleidoscope.)

Note that fault handling in Oracle SOA Suite 11g itself is covered in some previous blog posts, see part I, part II, part III, and part IV of Fault handling in Oracle SOA Suite 11g. These posts also discuss the use of custom fault handlers. There are some steps involved to create and deploy a custom fault handler. First time around this can be a non-trivial task. The steps required to deploy a custom fault handler are documenten in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Website users in different stages of the experience lifecycle

Creating Vennster.nl - Part 1

As you might know we as Vennster are an independent company since the beginning of 2011. As part of the process, we changed our name and our branding style. Now it’s time to develop our own website - Vennster.nl. Of course we do that in a way we also would when designing a website for one of our customers using the appropriate methods and tools.

The first and most important step is to determine who the target audience of our website is.

In the lifecycle of experiencing the services/products of your company, users of your website can be in different stages. They can be…

…Visitors

• Don’t know you (very well)
• Become aware of you: the company & the people
• Explore your services/products
• Compare your company with similar companies
• Might become a customer

…Customers

• Are already making use of your services/products
• Wonder what more you have to offer
• Want to know what there is to benefit

…Relations

• Know you very well – are loyal fans
• Need information in more depth
• Want to know about new things
• Want to share knowledge
• Might recommend your services/products to others

All three user types…

• ...have different needs when visiting the site.
  Relations are familiar with your way of doing business, the methods you use. Visitors might not be, they need more explanation.
• ...look at the information from different points of view.
• ...might enter a website via different channels. Therefore you need to be sure that your website is findable in all different ways. Visitors will use Google, customers might use (part of) the URL and relations may have (a certain page of) your website in their list of favorites. Therefore users will not always land on your homepage but will very likely end up somewhere else in your site. This means you have to make sure that it is easy to navigate from anywhere in the website. If you want to know more about ‘the Total Experience Lifecycle’ check out the website of Akendi, partner from Vennster in UX-design from Canada: http://www.akendi.com/end-to-end-experience-design-process/akendi-experience-lifecycle.php.

First we determined who we want to target with our website. Due to the nature of our services our target audience consists of people with very different professions and skills. In order to find out who these users of our Vennster.nl-site really are, we used a common technique: describing personas; a realistic picture of a person that represents a specific part of the target group for the service/product/website we have to offer them. In our case there is a need for personas in different stages of the relationship describing the visitor, the customer and the relation.

In my next blog I will explain how we created such a realistic picture and why this is necessary.

Start Small, Grow Fast | Companion Checklist

A companion checklist that summarizes the Oracle SOA Suite best practices contained in the "Start Small, Grow Fast" Oracle whitepaper by Demed L'Her, Edwin Biemond, and Ronald van Luttikhuizen at bit.ly/soa-start-small.

Administrative considerations

• Involve operations teams from the beginning.
• Make sure your organization has dedicated middleware administrators.
• Prefer scripting for deployment of composites.
• Use SOA Suite configuration plans to capture all environment-specific information instead of hardcoding them in your composites.
• Avoid creating a separate configuration plan per composite per environment - consolidate these to a few or a single configuration plan per environment.
• Script as many configuration tasks as possible from the beginning.
• Document configurations in a well-known central location such as a team Wiki, readily available to all stakeholders.
• Consider using NFS shares for JCA adapter configuration plans.
• Use partitions to categorize composites and execute various tasks for multiple composites at once.
• Use composite sensors to enable the search of specific instances.
• Negative testing is an absolute requirement.

Infrastructure considerations

• Build a cluster from the start -even if only with a single node. Think of the following when configuring a cluster:
• Use individual IP addresses for all components (WebLogic Admin Server, Node Manager, and the Managed Servers).
• Use the JRockit JVM and Mission Control to detect problems and perform tuning.
• Leverage WebLogic channels to separate cluster traffic from production traffic.
• Use a load balancer to divide traffic between services and detect outages of servers in the cluster.
• Think about your domains. There is no such thing as a “one-size fits all” domain topology; however there are a few tips and guidelines in this area:
• Always setup Node Manager.
• Do not combine Admin and Managed Servers; except maybe in non-critical environments such as development.
• Deploy your software and services to Managed Servers.
• Leverage domains to partition environments with different lifecycles or significant functional differences.
• Dedicate the most performant hardware to Managed Servers.
• Linux x86 is a great entry-level platform for Oracle SOA Suite.
• Favor Oracle Database as infrastructure database.
• Perform realistic load tests.
• Define and test a purging procedure well before going live.

Design-time considerations

• Use MDS to centrally store artifacts and avoid duplication.
• Have a canonical model for your core objects to ensure future re-use and consistency.
• Consider taking a contract-first or meet-in-the-middle approach for interfaces exposed to the outside world.
• Formulate and adhere to a small set of service design guidelines and naming conventions:
• Language conventions
• Naming conventions for composites, services, references and components
• Naming conventions for BPEL and BPM components and activities
• Naming conventions for composite sensors
• Wrap frequently used SOA Suite APIs in simpler custom APIs.
• Use Domain-Value Maps (DVM) and Business Rules to improve flexibility and agility.
• Use fault policy files to separate exception and fault handling from “normal” process logic. Centrally store them in MDS to enable re-use across composites.
• Unit test your composites using SOA Suite’s test framework as you would unit test your Java code using e.g. JUnit.

Architectural considerations

• Use a simple and concrete service categorization.
• Spend some time thinking about the granularity of your services to avoid too frequent refactoring. Reusability is a key factor. Other factors are rate of change, availability, and ownership.
• Building asynchronicity through business events or messaging will improve loose-coupling, ease of deployment and administration and enable throttling.
• Consider supporting multiple versions of the same service in production to allow service consumers to upgrade at their own pace.
• SOA governance is needed but can start very simply with a wiki. Consider a full-fledge repository as you grown your SOA efforts.