Skip to Content

Designing for social change

/wp-content/uploads/2011/11/worldusabilityday_303116.pngNovember 10 was World Usability Day – who knew? More interesting was the fact that SAP was a sponsor and a local event was held in Mannheim, Germany on that day. The theme was “Designing for social change” – though I don’t really know what that definitely means I am guessing a lot of it has to do with working with usability for the greater good – a lofty aspiration for usability design I would have thought.

The theme itself interestingly, seems to have kicked off with the Usability Professionals Association 2011 International Conference in Atlanta in June and then continued into November with this designated ‘day’.  Diego Mendes briefly outlines the proceedings of the UPA conference in his blog and rightly says

most UX folks have a genuine commitment to designing products that will change peoples (sic)  lives, almost all of them still work in a for profit company/business. Therefore, products that only create social change are not enough – Future successful social change products ought to create win-win situations, where the user will benefit from incredible products resulted from the multidisciplinary work of design, research, innovation and strategy teams. These products will add value to users because they will allow for social and environmental change and because they will generate revenue for the companies designing them.

I thought about this a little while working with our India based engineering team and then again as I refreshed some design facets  for upcoming Winshuttle products and then considered how different the world of design of self contained applications is, relative to the design work that many software developers will do for their respective organizations in the SAP space. A .NET aplication after all has many more opportunities to be written well or with a slick UI as compared to a native SAP program. But is that assertion really true?

To a certain extent you are constrained by some of the design elements that are available to you in the building of dynpros and web dynpros but I really wonder whether laziness doesn’t prevail in the bad SAP UI design in-house.  A recent blog post by Pete Lagana of Excellis for example really highlights why ‘ootb’ (Out Of the Box) UIs in particular miss the mark for many scenarios because they don’t cater to the nuanced ‘effect’ and vision that the sponsor or application owner has for the solution.

Many application development initiatives are driven by sponsors either by demo-ware aligned with aspirations, an intense frustration with the existing usability or a significant gap in the functionality of a given application. There will be other reasons too, but I think these are some of the major ones. 

Using a generic set of standard controls and application objects will almost always result in a bland or seemingly kludged experience relative to expectations for which SAP applications are notorious, irrespective of whether they have been written as BSP, Dynpros, web dynpros etc.

The reason for this, to me at least, seems to be that if you consider demo-ware impressions, those are often tweaked with a very specific experience in mind – they’re often focused on a very specific problem:solution. Extra special effort may have been invested in making sure that a ‘just so’ experience was had. If anything, the demo shows potential but it doesn’t always indicate the associated effort that needs to be put into the solution. Effort that perhaps internal business developers are inexperienced with. Or design elements that perhaps they are disinclined to apply effort into building.

Demos also often involve many participants in the engineering of them, a product manager, a marketing or sales person perhaps, and then of course the developer(s); there may even have been a usability expert involved.  In house developed solutions of which there are many out there, often don’t have the same degree of creation by committee resources and as a result are probably based more on what the developer can recycle from existing code, achieving the objectives outlined by the requirements and then getting the finished product validated by an analyst of perhaps a sampling of business users all against an unbearable time-line. Usability is considered but it is not focal to the solution, the end result therefore may actually then detract from the overall work experience of the end-user rather than enrich it.

So the ideal of a world usability day is interesting at least to Ecohub partners who need to embrace  the notion that their products an enrich the lives of existing and new SAP users since their inability to do this will ultimately lead to their inability to sell products and services however  it is probably an ambitious leap of faith for those who rely exclusively on internal developers and developers of purely ABAP based code unless there is a change in thinking on the part of those developers and possibly even some reeducation. 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.