So I have a few questions to start this thread off. Let's start from
the beginning.
1) I must admit until last year I hadn�t even heard of user experience
(UX) and I mistakenly thought it was the same as UI design. I know
better now, but I�m sure it�s a common mistake. How do you go about
differentiating the role?
2) How does somebody even get into the area of user experience?
CM.
On 16/01/12 6:48 PM, Ultan � Broin (Oracle Applications User Experience)
wrote:
> Yep, I am that user experience advocate. I�ve been in Oracle for 16
> years, first with Oracle E-Business Suite globalization development
> and now in the Oracle Fusion Applications User Experience (Apps-UX)
> team. Apps-UX enables applications developers and implementors to meet
> business objectives by providing usability guidance, best practices,
> and advice about making really usable apps.
>
> I engage with developers of ADF apps to get a conversation going about
> enterprise apps usability, enabling users to be more efficient,
> effective, and satisfied when they use those ADF apps in work.
>
> Usability is a business requirement. The benefits for enterprise apps
> like you are productive users, faster adoption of apps, less support
> and training required, great feedback, requests for more of the same,
> and less grief. If a user of your apps comes up to you after
> deployment and says �But all I wanted was��, then we need to talk
> about showing some ROI instead.
>
> I can explain more about usability�in plain language�and what guidance
> Apps-UX can provide, as well as try and answer any questions you might
> have. I am also interested in knowing if, or how, you incorporated
> usability into ADF development before.
>
> As a taster, check out the following:
>
> New User Experience Enhancements Improve Oracle E-Business Suite
> 12.1.3 Software: http://www.oracle.com/webfolder/ux/applications/successStories/101206_EBS.html
>
> Oracle ADF Enterprise Application Development--Made Simple: Review and
> Opportunity: http://blogs.oracle.com/userassistance/entry/oracle_adf_enterprise_application_development
>
> Looking forward to hearing from you.
>
> Ultan
>
> -------------------
>
> Ultan � Broin | Director Global User Experience | Applications User
It's interesting once you started to describe the role of the UX
engineer, I moved away from comparing the role to UI designers, and more
to the system/business analyst side. In reality the UX engineer covers
all of those roles, more holistically, from the beginning to the end of
the project.
Now unfortunately most of the members of this group don't have access to
an unlimited talent pool of UX engineers at cheap rates. In turn
(relatively speaking) many of the ADF systems worked on will be much
much smaller then Fusion Apps where there might be a few developers and
an analyst no more. With this in mind, would you have some
recommendations on:
a) How small teams can start learning more about UX
b) What material the Oracle UX team have put out in the public space for
specifically ADF developers to make use of (I know this is a recap of
some of your points already, but to summarize please)
c) If there's one UX goal any team should take on board now, what should
it be?
Finally regarding "Ah, that other blog entry is a plea for design around
tasks and not the data schema,logical order and disclosure of
information." Hallelujah! A big bug bear of mine in developing ADF
systems on top of existing databases is the existing data model drives
the design. Just yesterday I was chatting to a friend in the insurance
industry who was saying his company has no hope of better satisfying
their customer because all their systems are based around a central
entity "policy" rather than "customer". Of course it wasn't just the
database design that was skewed, in turn the business analysts, the
management and even the users couldn't break themselves out of the
"policy" box when trying to design new systems, making change very
difficult indeed.
CM.
On 18/01/12 2:50 AM, Ultan � Broin (Oracle Applications User Experience)
wrote:
There is one problem, however, that a data model that works for user A,
might not work for user B. My classic example is a purchase
request/purchase order system where user A requests items for his/her
office, which manager B must approve, and purchasing officer C must
order from vendors. C will get a stream of approved requests, but may
want to disassemble and recombine the requests into purchase orders.
Two requests for five pencils might best be combined into an order for a
box of ten. One vendor might have better prices for chairs, while
another better prices for desks, yet a single request is for a chair and
a desk. And when the items arrive, they have to be distributed back to
the original requestors. Managers may have needs to summarize purchases
in ways that are not related to individual requests or orders.
Compromises must be made to come up with a data model that works well
enough for everyone. Then you do the best you can to do a good design
for each user's tasks.
----