Are you ready to wear your UX hat when duty calls?

Featured
16393 Views
32 Comments
7 Likes

In an ideal world, all software projects would have an interaction designer or user experience (UX) specialist working with the team to ensure that the product is designed in a way that truly satisfies the needs of end-users. In a software project with separate business analyst and interaction designer roles, the work of these professional is complementary. While a BA is making sure the business requirements are well defined and understood, the UX professional may be researching the user segments and creating personas to represent their needs, goals, and related tasks.

In this interview with Laura Brandenburg, UX specialist Patrick Quattlebaum describes the benefits of introducing user experience  in a project’s early stages:

The value of UX early in the process is to introduce the user lens to this upfront work. At a minimum, user research has also brought some feature ideas to the table, and feature prioritization involves finding the sweet spot of features that align business with user value and can be built and maintained within the technology constraints. Ideally, UX has helped frame the design problem around business goals and user goals, not technology. We bring our understanding of human behavior to the process because we see users as the key integration point.

A project is much more likely to receive help from user interaction and usability specialists when its product is a high-profile commercial software or web application. For internal applications and non-commercial customer-facing software (such as Internet Banking applications), it is common for a project to unfold without the involvement of a UI/UX professional, and with complete disregard to considerations of what is valuable for the user in the first place.

UX - Are you ready to wear your UX hat when duty calls?A UX designer helps create business value by shaping software products in a way that increases the likelihood of achieving the intended outcomes of their use. Without the influence of  a user experience advocate, it is common for the development team to direct its attention exclusively to individual features and functions described in the requirements, implementing a design that allows users to complete tasks, but not necessarily achieve their goals or solve their problems. As Alan Cooper points out in his book The Inmates are Running the Asylum, “programming is such a difficult and absorbing task that eliminates all other considerations, including the concerns of the user”.

As an example, consider a support person who is talking with a customer over the phone. The customer has several service request tickets she wants to discuss, but the system only allows the employee to view and update the details of one ticket at a time. Each time the customer talks about a different ticket, the employee has to go back to a search page and reenter the name of the customer to get the list of the open tickets and select the appropriate one . The process to open and update each of the customer's tickets is slow, prone to errors, and frustrating both to the support person and the customer. All the required functions--select a customer, open a ticket, update a ticket--are there, but organized in a way that does not reflect the actual user needs.

In order to avoid user experience problems in their projects, business analysts may need to step up to the plate and take on the additional role of interaction designer. In fact, after performing some analytical work, a BA may very well discover that improving the user experience is the fundamental problem that needs to be solved by a project. This reality is more frequently when a software product has been already built, and feedback from users (before or after the application is put in production) indicates that the main problems are a not a result of missing or inadequate features and functions, but rather of the difficulty of using them. However, if a project starting from scratch is lacking a clear user interaction strategy, it is a good idea for the BA to include, in the business analysis work plan, user interaction design activities related to thinking through the interaction aspects of the product, defining the personas, and articulating the problems that the design must solve.

A few years ago, I was hired as a BA to help a team responsible for an internal web application that had a huge list of items in the product backlog, with requests ranging from additional reports to more details to be displayed on a page. My first task was to help the business stakeholders reprioritize the items in the backlog. Many of these items had been made obsolete by changes already made to the system, and several included requests that conflicted with each other. After the review of the backlog items was completed, it became clear that most of the change requests that were still relevant didn’t address the root cause of the problem: a poorly designed user interaction.

To determine whether the point of failure is the way users interact with the functions and features of the system, rather than the functionality itself, a BA may have some analysis to perform. In the example above, this understanding came as a result of interviews, research of system behavior, and observation of how employees who used the system actually worked. Through this process, I was able to identify critical design requirements that had been overlooked. For example:

  • It was established that the needs underneath the request for new reports could be easily fulfilled by the “advanced search” functionality. Only a few users were taking advantage of the the advanced search properties because the choices to filter results were not presented in a way that was intuitive to the majority of the employees. Adding more reports would only clutter the user interface; the real solution consisted in redesiging the look and feel of the advanced search page to facilitate user inquiries and saving these inquiries for future reuse.

  • Data fields that users wanted to be included on a page turned out to be easily accessible through an option to expand the details of a record with a simple click (if a user preferred to always see the expanded view, he/she would have to use the option to expand only once, as the system already had a built-in feature to make it a “sticky” preference). Again, the problem was not the system behavior, but rather a non-intuitive design that prevented users from noticing that useful collapse/expand functionality that was already available for them.

A business analyst joining a project that doesn’t include a user interaction specialist should be ready to take on the responsibility to help the project team design a product that doesn’t create obstacles for customers to achieve their goals, or employees to perform their jobs. By forgoing this initiative, the analyst may be unwittingly contributing to the creation of feature-rich but hard-to-use products that continue to frustrate users no matter how many new reports, features and functions are introduced to the application. A BA who feels comfortable wearing the hat of UX designer will be in an strategic position to take into consideration the “human  factors” that can make a software product not only efficient and usable, but also easy to learn and pleasurable to use. 

To learn more about user interaction design, check out these resources:

Interaction-design.org
Interaction Design Association Resources page
Jakob Nielsen's Alertbox
Recommended books

Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions.

Like this article:
  7 members liked this article
Featured
16393 Views
32 Comments
7 Likes

COMMENTS

arbora2 posted on Tuesday, March 15, 2011 8:50 AM
Link to recommended books is broken. 404 error.
posted on Tuesday, March 15, 2011 2:36 PM
Good information on the UX role, but the conclusion troubles me. Having recently served as a UI designer/BA when my forte is as a BA, I dusted off my publishing experience and found it to be a wretched foundation for the online world.

There is a reason the UX role exists and companies need to realize that interactive media requires research, insight into human factors and planning that a BA is ill prepared to deliver. Develop an awareness? Absolutely - by learning from the UX people you work with. Have one available to recommend when the role isn't filled. And while you are at it - recommend a graphic designer and a content editor too!

I found from experience that the pros think about a webpage very differently than I do.
Each role has specific work to focus on, so encourage proper staffing so that can take place.

If you have ever taken umbrage to someone in a different role who tried to do your BA work, think of that in this situation. Experts are experts for a reason.
ColemanTO posted on Tuesday, March 15, 2011 9:16 PM
Book recommendations are here:

http://bealprojects.com/BA/books/
adrianab posted on Wednesday, March 16, 2011 9:09 PM
@arbora2: My apologies for the broken link. Not a good user experience :-). Should be working in a few minutes. Meanwhile, the most direct path for the UI recommended books is this: http://bealprojects.com/BA/books/UIbooks.html

@ColemanTO: thank you for posting the link to the book recommendations page. The URL changed and I forgot to redirect.

@kcphred: "There is a reason the UX role exists and companies need to realize that interactive media requires research, insight into human factors and planning that a BA is ill prepared to deliver."

We are in agreement here--the best results will always be achieved when you have experienced UX professionals on your team. As a consultant, I am constantly recommending the involvement of usability specialists and user interaction professionals in my projects. The article is not about dismissing the contribution of true UX professionals but rather, the need for the BA to step up to the plate when there is no expert available. It's unrealistic for a BA to expect to always have this type of professionals as part of a solution team. In the 10+ companies I consulted for in the past 6 years, only one had UX professionals contributing to the project. When so many companies still insist on having a blended PM/BA role in their projects, "encouraging proper staffing" is easier said than done.
zarfman posted on Sunday, March 20, 2011 8:42 PM

Greetings:

Finally, some recognition there is an actual end user.

However, it seems that we've added one more link to the chain. Why can't the BA do the user interface with the help of the end users?

Perhaps it would be more appropriate for the end user to do UX thing and hand it off to the BA, since they actually do the work/use the system.

Regards,

Zarfman



adrianab posted on Sunday, March 20, 2011 9:51 PM
@Zarfman: thank you for adding your comment and pertinent question.

"Why can't the BA do the user interface with the help of the end users?" or perhaps even "have the end user do the UX thing and hand it off to the BA"?

Indeed, I've worked in successful projects in which the former happened and worked very well. However, a series of conditions existed that aren't necessarily present in other projects, specially the fact that the end users actually knew what they needed, because we were replacing a legacy system or enhancing an existing one and they were quite used to the tasks they had to perform to achieve their goals.

In books like "Subject to Change" (which is in the list of recommended books), you can see examples of products that would never existed if you had asked users to design it. The iPod is a famous case: users wouldn't be able with come up with Apple' s experience strategy of creating a system broken down into three segments (acquire media, manage media, listen to or watch media) that seamlessly connect to allow users to do everything they want without unnecessary functionality getting in the way when it's not needed.

You are correct to say that it is important to recognize that there is an "actual end user" (something many organizations, in particular when developing internal applications, tend to forget). However, users are much better at telling you about problems that they’re having than solutions that they want. For that reason, having a talented interaction designer in your team (or, if not possible, having the BA wear the "UX hat" will greatly increase the odds of a software solution delivering a superior user experience).
ColemanTO posted on Monday, March 21, 2011 9:56 AM
Users are not Designers.

http://theoatmeal.com/comics/design_hell
zarfman posted on Monday, March 21, 2011 2:18 PM
Greetings:

You wrote: However, a series of conditions existed that aren't
necessarily present in other projects, specially the fact that the end
users actually knew what they needed, because we were replacing a
legacy system or enhancing an existing one and they were quite used to
the tasks they had to perform ---

Zarfman writes: Why would anyone one start a project if the end
user’s didn’t know what they wanted? I can see where some exogenous
variable might confound them for some period of time. However, one
would hope the firm would eventually figure it out. Especially, if
there were legal and/or financial ramifications.

You wrote: In books like "Subject to Change" (which is in the list of
recommended books), you can see examples of products that would never
existed if you had asked users to design it. The iPod is a famous
case:

Zarfman writes: Before the IPod, we had small portable am/fm radios
(Dick Tracy started it all and Motorola had a hand in it also), then
Sony came up with what I think was called the Walkman that played
CD’s. Both had small earphones. The IPod required at least two other
technologies before it could be built. One very small disk drives 1”
or so and solid state memory. Sounds like fairly standard technical
evolution to me. Same for the IPhone, In the beginning they were
called car phones, and then came the bag phone.

You wrote: However, users are much better at telling you about
problems that they’re having than solutions that they want. For that
reason, having a talented interaction designer in your team (or, if
not possible, having the BA wear the "UX hat" will greatly increase
the odds of a software solution delivering a superior user
experience).

Zarfman writes: One of the major complaints I hear from user’s is
that we tell them we have problems and they never get fixed. Any
project management that ignores the end user/user interface should be
given the opportunity to work for the competition. By the way how
does one calculate user experience odds?

Regards,

Zarfman
zarfman posted on Monday, March 21, 2011 2:23 PM
Greetings:

I don't think I suggested that users were designers. However, since
they are users one would expect that they have certain preferences
and/or certain requirements placed on them given their job
requirements.

Moreover, all UX/Designers are not equal.

Regards,

zarfman
zarfman posted on Monday, March 21, 2011 2:39 PM

Greetings:

I find it somewhat depressing that this UX/interface thing is flopping around like a fish out of water after all these years.

Perhaps 20 years ago some dude from Microsoft published a book on interface design. It was quite detailed. It even covered the eye and color theory. It seems like every generation has to reinvent what has gone on before.

Regards,

Zarfman
adrianab posted on Monday, March 21, 2011 2:51 PM
@Zarfman:

"Why would anyone one start a project if the end user’s didn’t know what they wanted?"

Well, that's how Twitter, Skype and many other successful software products started
:-). From a problem or opportunity, not a solution that users already knew what it looked like. Even internal applications have the same effect: I've worked in projects in which executives knew what problem they had (for example, isolated information about business partners spread out among various business units) but nobody knew what the final solution should look like -- should they have the ability to see 3-D graphics with the aggregate information? Produce monthly or quarterly reports? Represent subsidiaries visually connected to their parent organizations? Etc. They know the problem they want to solve, but needed analysts and if possible user interaction specialists to help figure out the optimal solution.

"Zarfman writes: Before the IPod, we had small portable am/fm radios"

The iPod is not just about the actual device -- it's a 3-part system that Apple cleverly designed in a way that makes the user experience much better than previous solutions. It divides the focus on Play - Manage - Acquire. "The iPod device focuses on delivering the minimal set of functionality desired by someone on the go--playing media. Since Apple could assume that everyone with an iPod has a computer (it's the only way to get media onto the iPOd), Apple could place all other necessary functions in a piece of software -- iTunes)."

If Apple had let users design the iPod, they would have included everything they needed, including the ability to delete media, or rename items, or create playlists, in the actual device, which would then become much more difficult to operate. Those "manage media" functions are handled much more efficiently by iTunes. Smart designers were needed to create the 3 segments that seamlessly connect to provide a superior user experience.
adrianab posted on Monday, March 21, 2011 2:58 PM
"Perhaps 20 years ago some dude from Microsoft published a book on interface design. It was quite detailed. It even covered the eye and color theory. It seems like every generation has to reinvent what has gone on before."

Zarfman, please never use anything Microsoft ever published as a reference for user experience expertise :-).

The book "The Inmates are Running the Asylum -- Why High-Tech Products Drive Us Crazy and How to Restore the Sanity" would probably help you change your opinion that this trend of taking UX more seriously is just a rehash of old ideas.
zarfman posted on Monday, March 21, 2011 10:09 PM


Greetings:

With regard to executives knowing what problem they had. For publicly held companies GAAP requires these companies to adhere to certain rules. Share holders aren’t that much fun either. I’ve always been suspicious the term analyst, specialist and experts. How can one not trained in a specific art or science be expected to analyze that art or science. The more complex the art or science the utility of these analysts, specialists and experts is questionable. Having held positions such as CFO and VP I’ve met many individuals who claimed to understand accounting and finance WRONG not even close.
I would argue that less than 10 percent of those individuals who claim to be analysts, specialists and experts are actually what they claim to be. Mediocrity is rampant.

Also I despise the term optimal. It is a word stolen from the field of mathematical optimization and is grossly misused by others not familiar with the field.

I contend that technology evolves providing the foundation and tools for future users. DARPA was founded about 1958. Thanks to DARPA (not Al Gore) we have the internet.

If I recall correctly the Twitter dudes were podcasters first. Later they used SMS to develop twitter.

Skype another internet based product. I seriously doubt that Skype would exist today if it were not for eBay’s’ almost 3 billion dollars worth of funding.

Moreover, we have market research, consumer panels, alpha and beta testers etc. Most of which are surrogates for end users.

Let us consider apple and the IPod. You mention iPods’ focus on focus on Play - Manage - Acquire. Its precursor the Sony walkman did the same thing. I suspect that Apples engineers didn’t just design the iPod and turn it over to manufacturing and marketing. In fact I think much of its packaging is based on the work of some German designer from the 1960’s.

From end to end users rule, consider Microsoft’s Zune and countless others.

I’ve not read the books "The Inmates are Running the Asylum -- Why High-Tech Products Drive Us Crazy and How to Restore the Sanity” I may do so at some time in the future.

These books would probably help you change your opinion that this trend of taking UX more seriously is just a rehash of old ideas. I take UX and interface design very seriously. Over the years I’ve had to put up with designs that I and other users truly hated.

Call me one who is not very happy with the state of the art.

Zarfman
zarfman posted on Tuesday, March 22, 2011 12:29 AM
Greetings:

Zarfman complains some more.

It is written: The value of UX early in the process is to introduce the user lens to this upfront work.

Zarfman writes: What is a user lens and how do I know one when I see one?

It is written: At a minimum, user research has also brought some feature ideas to the table, and feature prioritization involves finding the sweet spot of features that align business with user value and can be built and maintained within the technology constraints.

Zarfman writes: By what methodology does one prioritize features. What is a sweet spot and how does one know when one has arrived there? What methodology is used to align business with user value and what are the alignment criteria? Technology constraints, I suspect the actual constraints are more of a people problem than one of technology.

It is written: Ideally, UX has helped frame the design problem around business goals and user goals.

Zarfman writes: Sounds reasonable on the face of it.

It is written: We bring our understanding of human behavior to the process because we see users as the key integration point.

Zarfman writes: Whose understanding? I’m not sure even shrinks understand human behavior. It seems talk therapy is out of vogue and shrinks have resorted to pills. I’m not sure about this thing called key integration point. Key seems to imply more than one point. Moreover, what are we integrating?

Zarfman concludes rather unkindly: Pretty much glittering generalities. Postulating an actual methodology is more helpful.

It is written: Without the influence of a user experience advocate, it is common for the development team to direct its attention exclusively to individual features and functions described in the requirements, implementing a design that allows users to complete tasks, but not necessarily achieve their goals or solve their problems.

Zarfman writes: Why can’t the UX be included in the requirements? If by implementing a design that allows users to complete tasks, but not necessarily achieve their goals or solve their problems. SOMEBODY REALY SCREWED UP.

It is written: As an example, consider a support person who is talking with a customer over the phone. The customer has several service request tickets she wants to discuss.

Zarfman writes: Several tickets, not a good sign, big red flag.

It is written: In order to avoid user experience problems in their projects, business analysts may need to step up to the plate and take on the additional role of interaction designer. In fact, after performing some analytical work, a BA may very well discover that improving the user experience is the fundamental problem that needs to be solved.

Zarfman writes: What kind of analytical work are we talking about? What are the tools and/or methodologies involved/required?

It’s time for me to stop complaining and do other things.

Zarfman
ColemanTO posted on Tuesday, March 22, 2011 9:25 AM
Bridging the Designer–User Gap:

http://www.useit.com/alertbox/designer-user-differences.html

"Don't ask them, watch them."
adrianab posted on Tuesday, March 22, 2011 1:14 PM
@Zarfman: I had to give up trying to continue to answer your questions and observations because most of them didn't make sense to me :-). I think we are coming from very different perspectives, and it would be useful if you read the books I mentioned before we could discuss particularities of what you agree or don't agree about the UX discipline.

I'll answer though your last question: "What kind of analytical work are we talking about? What are the tools and/or methodologies involved/required?" -- methods, practices and procedures used by the BA to achieve clarity about a business need and determine the solution, involving typical analysis techniques, such as data modeling, decision analysis, interface analysis, observation, root cause analysis, etc.
zarfman posted on Tuesday, March 22, 2011 7:53 PM

Greetings:

I will read "The Inmates are Running the Asylum -- Why High-Tech Products Drive Us Crazy and How to Restore the Sanity” if you will read Decisions with multiple objectives, Preferences and value trade-offs. By Keeney and Raffia. It's part of the Wiley series in probability and mathematical statistics.

DEAL?

With regard to my questions, I'm simply asking Quattlebaum or you to define his terms.

Regards,

Zarfman
adrianab posted on Tuesday, March 22, 2011 8:03 PM
@Zarfman: fair enough! It's a deal. I'll just need 4 weeks to wrap up a few projects and finish "The Decision Model: A Business Logic Framework Linking Business and Technology" which I'm currently reading (coincidentally, also with "Decision" in the name :-). Then I'll start the book you recommended.

Do send me an email at adriana [at] bealprojects.com so we can keep in touch and better coordinate our future discussion!
zarfman posted on Tuesday, March 22, 2011 8:04 PM
Greetings:

I ordered the book from amazon.

Zarfman
adrianab posted on Tuesday, March 22, 2011 8:05 PM
Cool -- I order all books from there as well -- will include in my next shipping!
ColemanTO posted on Tuesday, March 22, 2011 8:56 PM
Cooper on User-Led Design:

http://www.cooper.com/journal/2011/02/users_led_innovation.html
adrianab posted on Tuesday, March 22, 2011 8:58 PM
@ColemanTO -- thank you for the links!

The last one has this quote worth repeating:

"Ikea and Apple may not ask their users what they want, but they sure work diligently to understand what their users want. There is a world of difference between the two."

(And also between the two and Microsoft, I would add ;-)
ColemanTO posted on Tuesday, March 22, 2011 9:20 PM
More Cooper on UX:

http://channel9.msdn.com/Blogs/Charles/Alan-Cooper-Questions-after-his-keynote
ColemanTO posted on Tuesday, March 22, 2011 9:22 PM
"Never, never, EVER let users have ANYTHING to do with software!"
adrianab posted on Wednesday, March 23, 2011 3:36 PM
@ColemanTO: Cooper may have gone too far there, for emphasis purposes :-). He does prescribe "dont' ask them, watch them", which is indeed a much smarter approach than merely bringing in the users to tell us what they want, and good advice for BAs. It's always a good idea to focus on "what" and "why" when interviewing or observing users, rather than "how" they think something should be done done. Specially when you are replacing a legacy application, users' deep familiarity with the existing standards could easily lead the team to accepting and working around obstacles that could be removed by a talented designer looking at the problem with fresh eyes.

@Zarfman: I just realized that the book I recommended you has a message much more geared toward why you shouldn't let programmers create the interaction design of a software application than toward how interaction design expertise can make a big difference in the success of a product and its adoption rate. So, I'll extend our deal to say that after we discuss the two books we each selected, if I sense you are still not convinced of the latter, and you give me a shipping address, I'll send you a copy of "Subject to Change" so we can both look at the concepts of the book as a reference for the conversation (the book also explains what's different in the iPod approach from everything that came before, and it would be interesting to see your thoughts on that).






ColemanTO posted on Wednesday, March 23, 2011 8:21 PM
I agree--I think Cooper meant "don't let users do programming".

I'm a firm believer in User Testing throughout the development process.

Cooper outlines his process here:
http://www.cooper.com/journal/agile2008/
zarfman posted on Wednesday, March 23, 2011 8:25 PM
Greetings:

Coleman wrote: "Never, never, EVER let users have ANYTHING to do with software!".

Zarfman writes: If we assume a black box metaphor, if by software you mean what happens in the black box I would tend to agree.

However, I strongly assert that what data goes into and out of the black box as well as what is an acceptable time delay is the province of the user.

In my field of finance/accounting, the IRS, Financial Accounting Standards Board and the SEC have the power of law to enforce certain requirements. Ignoring these requirements is a form of corporate suicide.

Try understating your income by more than 25% for a year or two and see what happens.

Regards,

Zarfman
ColemanTO posted on Wednesday, March 23, 2011 8:52 PM
I dunno, junk bonds? Mortgage crisis? Global warming?

In the video, Cooper did touch on GAAS needing to change to put the correct valuation on software development.

BTW, There are organizations calling for just such revaluation to save the planet:

http://www.teebweb.org/


Cheers,
Tom
zarfman posted on Thursday, March 24, 2011 7:57 PM
Greetings:

For those of you who've seen my recommendation of the text Decisions with Multiple Objectives by Keeney and Raiffa I’m having second thoughts.

The reason being unless you are a have a very good command of higher mathematics you won’t be able to apply the techniques set forth. This text is often used in graduate level courses.


For a case with three attributes.

Example: The pair of attributes X and Y is preferentially independent of Z if the conditional preferences in the (x,y) space given z’ do not depend on z’.

Notice that if the pair {X,Y} is preferentially independent of Z, then the substitution rate between X and Y at the point (x1,y1) given z’ does not depend on z’, for all x1,y1 and z’. Thus the set of indifference curves in X,Y space does not depend on z’. Furthermore, because of the preferential independence condition, these curves have the same preference ordering.

Suppose that the pair (X,Y) is preferentially independent of Z. In this case we can say that if

(x1,y1,z’)>(x2,y2,z’) where the symbol > is read “preferred or indifferent to,” then

(x1,y1,z)>(x2,y2,z), for all z.

It gets worse. Back in the day I could handle the math, unfortunately, my stint in finance/accounting has ruined my math skills.

Regards,

Zarfman
adrianab posted on Thursday, March 24, 2011 8:28 PM
@Zarman: heehee. We may both have recommended the wrong books for the purposes we had.

I kind of like the example from the book! I might even speed up the ordering of my next shipping from Amazon just to check it out sooner :-). To be honest, higher mathematics is now looking a logt more appetizing than the "business logic framework linking business and technology" from The Decision Model, which I was reading. Even the authors note that you probably wouldn't be reading the book in its entirety, but at some point their position that their model is "easy to create, interpret, modify, and automate", got to me. I wouldn't call it "easy" by any measure, and I doubt any of my consulting clients would be interested in learning the models so I could actually use them in practice. Oh well.

Anyway, I'm curious because the book you recommended seems to be more oriented to the technical aspects of building a solution, whereas this article goes in the opposite direction, discussion the importance of the "human side" that needs to be accounted for so that a solution not only provides the necessary functionality, but also is easy and pleasant to use to encourage user adoption. What is the connection, if you don't mind explaining your rationale?
zarfman posted on Thursday, March 24, 2011 9:57 PM


It was written: I'll answer though your last question: "What kind of analytical work are we talking about? What are the tools and/or methodologies involved/required?" -- methods, practices and procedures used by the BA to achieve clarity about a business need and determine the solution, involving typical analysis techniques, such as data modeling, decision analysis, interface analysis, observation, root cause analysis, etc.

Zarfman writes: I picked up on the term decision analysis. I used the keeney example to show the power of mathematics when applied to decision analysis. Mathematics is the common language of science and engineering. That's how we communicate with each other. My contention is that until analysts in other domains start applying mathematics to the analytical problems they are facing that domain will evolve at snails pace if at all.

For example, one of the companies I worked for(along with several other companies) were asked for assistance in relocating an airport that had been destroyed by an earth quake. The other companies talked about their previous experience in that area using vague generalities. Our company presented site selection based on math based decision analysis, Our company blew the competition away.

In this case and cases like it the client didn't have to learn the model, Put in your parameters and you will get an answer. Including some you may not like or given your parameters there is no feasible solution. There are times when the client says I kind of understand what you're saying but I want the red one.

I don't know if I've answered your question or not.

Regards,

Zarfman
adrianab posted on Thursday, March 24, 2011 10:10 PM
You did! And makes sense -- thank you.

I am all for decision analysis, and will be interested in reading the book even if the math part is troubling.

"In this case and cases like it the client didn't have to learn the model, Put in your parameters and you will get an answer. "

Oh, but in the context of the book I'm reading, the client does have to learn the model, to be able to read the diagrams and sign-off on them, and also to maintain the model once the consultant is gone.

Only registered users may post comments.

 



 




Copyright 2006-2021 by Modern Analyst Media LLC