The Suffering of UX

In our preoccupation with designing the perfect user experience (UX) we fail to comprehend other key components that can play a role in enhancing the overall UX. If we turn a blind eye, then the UX is destined to suffer irrelevant of whether or not we have hammered out the perfect design. Two of the integral components that we must learn to more fully address, along with that flawless UX design itself, are:

Change Management - Change….this small, one syllable word seems to inspire fear among the masses. However, armed with a well-planned change management strategy we do not have to fear this puny little word. An organized change management strategy provides a structured approach to transitioning an organization (people, technology and all) from a current state to a desired future state. Yet, if this strategy is lacking organizations tend to resist and not embrace this change of state, which can lead to a breakdown in the UX and subsequently the implemented solution.

As consultants, we need to be considerate that change is an unnerving task for all involved; therefore, if we strive towards developing a well thought out change management strategy, then we help provide an environment welcoming of change and more supportive of a positive UX. The key to a well thought-out change management strategy lies in launching an effective communications plan that addresses the two most important questions that people need to hear, the “why” are we changing and the “result” or impact on us? In tackling these giants we can help ease organizational fears by providing answers to these daunting questions and allow users the chance to focus explicitly on their solution experience.

Comparing AX 2012 Reporting with Standard SSRS

I have been a Business Intelligence (BI) consultant for a couple of years, and I have worked with the whole suite of Microsoft BI products:  Reporting Services (SSRS), Integration Services (SSIS) and Analysis Services (SSAS).  Dynamics AX 2012; however, was an alien entity to me.  When I was asked to do reporting in Dynamics AX, I thought that since this is a Microsoft product that uses SSRS and a SQL Server database, this should be a pretty standard task based on my experience.  While I was correct from a front-end design point of view, actually getting the data to the report was quite a different task.

The first noticeable difference is the setup.  AX 2012 uses Visual Studio 2010 as opposed to Business Intelligence Development Studio (BIDS) to setup its reports.  BIDS leverages Visual Studio 2008 to launch and run SSRS and you make all of your connections, data sets and parameters directly in the report designer.  Visual Studio 2010 uses a tree view to manage all your data sets and parameters.  These objects must be added, modified or refreshed in the tree to translate over to the report designer. Changes can be made in report designer like in BIDS but they will not translate back to the tree and the changes will not stick.  BIDS creates an RDL file that can be reopened and edited.  With Dynamics AX 2012, everything is stored in the AOT and brought to the local machine by using temporary folders.