Oracle UX Asks a Question of ADF EMG: Your Experience of Usability as a Requirement for ADF Apps

[Ultan Ó Broin (Oracle Applications User Experience)]

OK, knowing what the end user wants from your your app, how they work,
and keeping their requirements central is important for successful
usability.

So, for your apps development, tell me about your experience of
making usability part of your requirements (or not). Did you engage
with real end users, and what did you ask them upfront about how they
worked, what they wanted, what their issues with apps usage were? Any
insights, observations to share? Did you evaluate the final app with
those users? How?

Or did you, or someone from the IT Dept, represent the end user and
take it from there?

[Chris Muir]

Hmmm nobody has answered so far must imply everybody is designing against different criteria, probably along the lines of my-boss-told-me-so ;-)

I am willing to admit I've never worked on a system where usability was a key requirement (and to be fair I write some of those requirements). Often the requirements have some vague comment about the system must be user friendly, but it's rarely explained what that is & as such the end system is built around the functional requirements.

This is not to say elements of usability don't "slip" in to the requirements. In a recent Forms to ADF conversion, a goal was to save the users having to drill up/down several Forms to see information about clients. Instead much of the information was aggregated on a dashboard like client ADF page.  In turn a task oriented menu was added to navigation rather than schema like navigation model in the existing Forms system.

As for engaging with real users, the question kind of shows who you work for.  For consultants working on the coal face it's all about client engagement, managing expectation, and many times changing requirements/implementations at a client's/user's whim, to keep the contract moving. Again though, is usability a key requirement? Well for me not till now ;-)

Who we actually engage with does differ per project & customer. Sometimes it's the real user, sometimes a "super user" (think domain knowledge expert), sometimes analysts, sometimes managers. Often who you can and cant engage with is dictated by the contract or sometimes the customer's internal politics/barriers. You take what you get and physical access to the real users can be hard on some projects.

CM.

> --
> You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
>

[Jan Vervecken]

hi Ultan

In my experience usability gets much less attention than functionality
of an application.
If some iterative development approach is used, the iterations allow
for feedback. And some of that feedback will be about usability and
sometimes from end users.

regards
Jan Vervecken

On Jan 18, 11:36 pm, Ultan Ó Broin (Oracle Applications User

[filip.h...@contribute.be]

Hi guys,

I follow Jan on this.
For the moment I'm on 2 projects with 2 different visions on
usability:
* first project: no importance, functionality is important and
consistency of usability
* second project: they build an app to resell; they use the same
techniques as Oracle Fusion Applications, or at least what is
mentioned in documents and blogs. They are also keen on being able to
input information without the use of the mouse.

Personally, I think you will get a lot more feedback when asking this
question to the webcenter guys, where usability, look&feel is far more
important then functionality (in absolute terms).

HTH

Filip Huysmans

[Jean-Marc Desvaux]

My 12c(ts)...

We take care of usability in the design & dev process but we do it in a more "artisanal" way than a scientific one...if I can say so.

One must take into account the fact that we only build apps for internal requirements (e.g Client is a single Organisation) and our IS service is also part of management decisions in term of where do we go and what do we do; the "How do we do" side is a near 100% IT effort.

We have five major implicit rules/guidelines : 

- simplify as much as we can.

- always design interface with an end-user hat and not a developer one.

- adhere to corporate standards (colors, look and style, etc..) and to what is considered to be a common denominator to all apps.

- leave to the developer his design freedom as far as he plays by the rules.

- Use the minimum number of dev tools for UI development, ideally one only (today we have two : Forms and Faces).

The steps basically for any new application module are :-

- Analysis of Processes and Data Model design including integration with existing Model.

- Sketches of UIs and brainstorming (done by IT only. End users can't really see behind sketches, we prefer a more mature application mock-up to start engaging the users).

- Integration in existing applications and security related discussions (separation of duties with flexibility).

- First validation of intentions against the Model.

- Dev.: Mock-up production (Beta 1 if you want).

- User Briefing and reaction/question <---- We expose the new application concepts and primary pages/screens and functionnalities without getting too much in the details.

- Realignment (Design/Model and Dev) where necessary following users reaction and issues raised during the briefing session.

- Dev. of apps to a first prod release level and Test the application.

- Tuning (Indexes, plsql packages used, review sql code in ADF and packages, review java code where required),

- Deployment on a pilot basis for some weeks and corrections where required.

- General Deployment and close follow up with users during the first weeks.

- Users feedbacks/comments are taken into consideration and implemented when justified at an organisational point of view (IS dept decision).

- The prod application is always kept "opened" to new end users input and further improvements.

What we are experiencing is that End-users usually need less than 2 weeks to digest and own their application part and internal Job/Staff rotations are rarely an issue and require less time to adapt because the user is already used to a similar type of application  he was using in his previous function.

One of the problem we have (other than time) if we want to engage the users more than what we actually do in the usability aspects is that each application module usually involves a limited number of users making the sampling small to work with.

-Jean-Marc

[Ultan Ó Broin (Oracle Applications User Experience [Apps Usability])]

Thanks for all the responses everybody, interesting stuff. Wondering
if agile development affords new opportunities for usability too.

U

[Andreas Koop]

We experience different types with respect to usability requirements

a. Customer is happy with what ADF components bring along according
usability. ( Functionality is everything)
b. Customer has an exact Imagination on Look and feel of the target
application. The Customer provides Screendesigns, norms and Standards
which Must be fulfilled by the final application
c. Customer migrates an existing application. She expects same
usability with adf application

Testdrives with real end users are Most of the Time Not possible. As
an internal guideline we follow
- simple as possible, few clicks as possible
- usable on mobile/ tablet device (although it is Not primaraly
targeted for such device type)
- "how would Steve do?" ;) well, although ist sounds funny there
customers that say "please implement/provide similar usability as we
are used to from apple Software"

Andreas.
--
Sent from iPad