Should a usability engineer have the knowledge about the professional area related to his products?

15 Oct 2007 - 8:15am
7 years ago
6 replies
674 reads
Yang Zhenyi
2007

I'm working for a software company which provides ERP application. And i
have a question : Should a usability engineer have the knowledge about the
professional area( such as accounting, supply chain management,
manufacture and so on)?

My major is cognitive psychology. When i started my job 2 years before, i
got so frustrated that i even can't understand what users talking.
Because i don't know what exact task they would do with our application. My
education background don't contain those knowledge. Fortunately, I have
some colleagues who are expert in thoese areas. We worked together on
interaction designing and user testing.

So in my opinion, the knowledge about the professional area is
very important to a usability engineer, especially when he is working for a
complex application system. But for the other side, it takes too much time
to master those knowledge. For me, i still avoid to hold a user
interview independently after 2 years later.It takes about 5 years to become
an expert of the application.

I had got some other's opinion that a usability engineer doesn't need to
know such knowledge at all( but i didn't catch it clearly). What's your idea
?

Thank you!

Yang Zhenyi

Comments

15 Oct 2007 - 8:38am
Steven Chalmers
2007

It is indeed very useful to understand the user's job when designing or modifying an application for them. Understanding what the user's objective is in using the tool allows the designer to make the tool effective.

That said it is always possible to improve software with minimal understanding of the domain. In every contract or job I have had I was able to contribute the first day. There are almost always things in the interface that can be improved with the application of basic usability principles.

In most of my jobs/contracts it takes me 6 to 9 months to get enough understanding of the user's job and the domain before I feel comfortable attempting a redesign of the entire application. In the mean time I am making incremental improvements in more isolated areas. After spending enough time making smaller changes I usually have gained enough expertience to tackle the application rewrite, if that is what the client wanted.

Steven

15 Oct 2007 - 8:26am
david.shaw6@gma...
2004

This is almost a given. You have to understand the business that
you're working in (sometimes you can learn it too) in order to
properly design something. As an example, I work in heathcare
currently. If I didn't have some type of understanding of how this
industry works, not only would I be designing things that may be
inappropriate to a certain workflow, but I also might actually cause
serious patient issues.

Not that you need to have that specific knowledge coming into a
particular position, but you need to have a strong desire and ability
to learn the domain quickly.

On 10/15/07, 振奕杨 <yzy205 at gmail.com> wrote:
> I'm working for a software company which provides ERP application. And i
> have a question : Should a usability engineer have the knowledge about the
> professional area( such as accounting, supply chain management,
> manufacture and so on)?
>
> My major is cognitive psychology. When i started my job 2 years before, i
> got so frustrated that i even can't understand what users talking.
> Because i don't know what exact task they would do with our application. My
> education background don't contain those knowledge. Fortunately, I have
> some colleagues who are expert in thoese areas. We worked together on
> interaction designing and user testing.
>
> So in my opinion, the knowledge about the professional area is
> very important to a usability engineer, especially when he is working for a
> complex application system. But for the other side, it takes too much time
> to master those knowledge. For me, i still avoid to hold a user
> interview independently after 2 years later.It takes about 5 years to become
> an expert of the application.
>
> I had got some other's opinion that a usability engineer doesn't need to
> know such knowledge at all( but i didn't catch it clearly). What's your idea
> ?
>
> Thank you!
>
> Yang Zhenyi
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help
>

--

w: http://www.davidshaw.info

15 Oct 2007 - 8:33am
Jarod Tang
2007

> This is almost a given. You have to understand the business that
> you're working in (sometimes you can learn it too) in order to
> properly design something. As an example, I work in heathcare
> currently. If I didn't have some type of understanding of how this
> industry works, not only would I be designing things that may be
> inappropriate to a certain workflow, but I also might actually cause
> serious patient issues.

Exactly, and the insight about the give domain is almost one of most
essential elements for design success. not only know it, but have
insight about what it should be, what's the factor that affect the
effectiveness and user experience.

Cheers
-- Jarod
--
IxD for better life style.

http://jarodtang.blogspot.com

15 Oct 2007 - 9:06am
Jarod Tang
2007

One more comment, to gain insight about how the user accomplish his
stuff, is the key for the interaction design, and that's the root
cause for why the designer should not only know but also hold insight
about the domain that the user works in.

Cheers
-- Jarod

On 10/15/07, Jarod Tang <jarod.tang at gmail.com> wrote:
> > This is almost a given. You have to understand the business that
> > you're working in (sometimes you can learn it too) in order to
> > properly design something. As an example, I work in heathcare
> > currently. If I didn't have some type of understanding of how this
> > industry works, not only would I be designing things that may be
> > inappropriate to a certain workflow, but I also might actually cause
> > serious patient issues.
>
> Exactly, and the insight about the give domain is almost one of most
> essential elements for design success. not only know it, but have
> insight about what it should be, what's the factor that affect the
> effectiveness and user experience.
>
> Cheers
> -- Jarod
> --
> IxD for better life style.
>
> http://jarodtang.blogspot.com
>

--
IxD for better life style.

http://jarodtang.blogspot.com

15 Oct 2007 - 11:50pm
bhakti भक्ति
2006

Hello Friends,
This is an interesting discussion. I would like to share my experience.

The business area for our product is audit. Having a know-how of audit
domain has proven advantageous especially during the user councils and data
gathering sessions.
Domain knowledge in our case has made it one step easier to understand our
users, relate to them and their processes.
Especially when they have a typical query which can be addressed
with existing work around in the product can be resolved further provides
insight to fine tune on the usability of the product.

Experience goes like this:
Background:
We had a feature for a functionality around benchmarking objects for
comparing with the current objects. Here the user selects the parent object,
then children for benchmarking.
The user feedback was: There are cases when they are not aware of the parent
but have defined the children for selection for benchmarking.

Feature:
Required selection of parent and then its children objects.

Advantage:
We know how the auditors work on this particular feature.

Solution proposed for the current timeline.
Provide an additional search option for underlying child objects to filter
out the parent object and display enabled in the child object bucket on the
UI. The user could then easily search/select child objects.

Please share your experiences as well.

My 2 cents,
Bhakti

16 Oct 2007 - 9:25am
Melvin Jay Kumar
2007

My basic opinion.

You have to understand what you are going to test.

But you don't need to have in-dept knowledge of everything in order to do that.

Also , if itstead you are talking about designing, then yes,
definitely agree you need ot understand whole lot more on various
perspectives in order to design a proper product that meets both the
business as user experience needs.

Regards,

Melvin Jay Kumar

On 10/16/07, bhakti भक्ति <bhakti.khandekar at gmail.com> wrote:
> Hello Friends,
> This is an interesting discussion. I would like to share my experience.
>
> The business area for our product is audit. Having a know-how of audit
> domain has proven advantageous especially during the user councils and data
> gathering sessions.
> Domain knowledge in our case has made it one step easier to understand our
> users, relate to them and their processes.
> Especially when they have a typical query which can be addressed
> with existing work around in the product can be resolved further provides
> insight to fine tune on the usability of the product.
>
> Experience goes like this:
> Background:
> We had a feature for a functionality around benchmarking objects for
> comparing with the current objects. Here the user selects the parent object,
> then children for benchmarking.
> The user feedback was: There are cases when they are not aware of the parent
> but have defined the children for selection for benchmarking.
>
> Feature:
> Required selection of parent and then its children objects.
>
> Advantage:
> We know how the auditors work on this particular feature.
>
> Solution proposed for the current timeline.
> Provide an additional search option for underlying child objects to filter
> out the parent object and display enabled in the child object bucket on the
> UI. The user could then easily search/select child objects.
>
> Please share your experiences as well.
>
> My 2 cents,
> Bhakti
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help
>

Syndicate content Get the feed