Human Information Interaction (HII)

Posted by

a083c-4fc13-image-asset

@Laura Downey I thought I’d take your suggestion and start a separate thread re HII.  @Alan Frank I thought you’d be interested.

I think that most of the time when I end up having a discussion with folks about design they stop at wireframes (pictures) and fail to see the interaction patterns.  Some of that is a lack of the systems thinking and some of it is — I believe — that they don’t really understand how to do story boarding (or I suppose even how to tell a story at some level).

I think that we can draw processes when they’re clearly defined and discrete but I think all of us — myself included — struggle to manage to completely grok everything that goes into HII when the processes aren’t distinct.

What are your thoughts about how we can break it down into more manageable chunks?

——————————
Robert Bogue
President
Thor Projects LLC
——————————


a083c-4fc13-image-asset

@Laura Downey I thought I’d take your suggestion and start a separate thread re HII.  @Alan Frank I thought you’d be interested.

I think that most of the time when I end up having a discussion with folks about design they stop at wireframes (pictures) and fail to see the interaction patterns.  Some of that is a lack of the systems thinking and some of it is — I believe — that they don’t really understand how to do story boarding (or I suppose even how to tell a story at some level).

I think that we can draw processes when they’re clearly defined and discrete but I think all of us — myself included — struggle to manage to completely grok everything that goes into HII when the processes aren’t distinct.

What are your thoughts about how we can break it down into more manageable chunks?

——————————
Robert Bogue
President
Thor Projects LLC
——————————


a083c-4fc13-image-asset

I totally agree with your observation regarding wireframes and the lack of exploration of interaction patterns. After struggling with that issue for years, my take is:
-Root-cause of the problem is the lack of understanding how to create IM business metrics. I have seen a number of lean exercises become technology project instead of business projects.
– My response has been to emphasis business metrics up front and use those metrics to create distinct “business process units”. If it is not obvious how the business process impacts the business metric – go back and rethink the segmentation behind the process unit.
– Once you have designated the unit, you can identify the inputs, the process / transformation (differentiating the technology from the human behavior), and the outputs that are “counted” to create the business metric. (I have always considered this a marriage between “Object Oriented Descriptions” and what is now called “Lean”, although I am always defending my interpretation of both.)

This is probably the first time I have ever phrased this process in so few sentences so feel free to poke and the description.
Alan Frank

——————————
Alan Frank
Business Process Analyst
ASF Consulting
PhD, CIP, IGP
——————————


a083c-4fc13-image-asset
@Robert Bogue

As a recent participant without the benefit of full context, I think one way to break down “all that goes into HII into more manageable chunks” is to consider this “all” at a higher level of abstraction.  I mean:  to consider humans as “beings” who, together with “things” — information, concepts, relations, language, hw/sw… included — are organized according to a configuration which changes along time.  I.e, a version of the ontological truth.

At this high level of abstraction, interaction patterns are relations among things, semantically, grammatically and logically definable as an ontology restricted to the scope of the context at hand.  So, instead of wireframes, we would draw concepts connected via relations with information (as things) transmitted by language made by words which mean exactly this etc… Higher abstraction, more manageable chunks. My 2 cents.
Pedro


Pedro M. Correa

Sr. Regional Business Development Manager

Papyrus Software, Inc.
301 Bank St., Southlake, TX 76092, United States
T: 817-416-2345 | F: 817-416-1223
Juliane.Cuneus@…
www.isis-papyrus.com | Twitter | LinkedIn
This e-mail is only intended for the recipient and not legally binding.
Unauthorized use, publication, reproduction or disclosure of the
content of this e-mail is not permitted. This e-mail has been checked
for known viruses, but Papyrus Software accepts no responsibility
for malicious or inappropriate content.
   Image                                                           result for                                                           "nexxt"                                                           icon


a083c-4fc13-image-asset
Pedro –

I’m not sure that higher levels of abstraction make this better.  I think about this from a KM perspective where the more you abstract (or remove context) the more challenging that it becomes to make things actionable.  I think that when we’re developing algorithms we necessarily must remove context — but when dealing with people, I think the whole point of interaction is to give them a frame in which to operate.

I think that our patterns should be based on principles which we convert into rules that we encourage people to follow.

How would you propose that you teach a BA, a designer, or another professional about HII with so much abstraction?

Rob

——————————
Robert Bogue
President
Thor Projects LLC
——————————


a083c-4fc13-image-asset

Hi Rob,
Thanks for your feedback.  It is a very interesting topic – it’s gotten me squeezing synapses 😉

In my opinion, abstracting doesn’t “remove context” as you’ve put it.  It changes it (from specific to generic), but I don’t see it as removing it.
So, answering your question “how…. to teach a BA, a designer, or another professional about HII?”  I’d do it starting with a HII ontology.

This HII ontology would capture the key pertinent “THINGS” (concepts, their relationships, the semantic of words used to describe pertinent data & attributes, beings/actors…, how they’re engaged in relevant processes in the HII lifecycle, goals, rules, typical configurations/patterns, how they evolve in time, emotions, decision-making, Kahneman’s systems 1 & 2 etc…) all these HII “building blocks” in high, generic level of abstraction.

Eventually, when necessary to evaluate/analyze use cases at a specific/lower level – where the rubber meets the road – I’d instantiate a specific configuration of the ontology (like a picture defining contextual scope boundaries – what’s in & what’s out) and dive deep into the details of each building block, targeting the requirements/goals of the case at hand.  Ex: how to address HII needs of a heavy mining equipment operator who needs to absorb data displayed in a monitor inside his cabin to make decisions, while operating tons of steel equipment with gloved hands?…

I don’t believe this approach is a silver bullet, but it can be an alternative worthy of assessment, regarding how to start the HII work.

Best regards,
Pedro

——————————
Pedro Correa
Sr Business Development Mgr, Americas
Papyrus Software
——————————


Pedro,

A very ‘enterprise architecture’ approach to the problem.  Which, I agree can be one potentially viable route to addressing the issue.  That said, I also see Rob’s point where abstraction can easily (and often does) turn into just a modelling exercise which fails to generate practical outcomes.  A most interesting puzzle you’ve got going on here! ��

Aria

Aria Business Card-0۸
Aria Business Card-۱۰


a083c-4fc13-image-asset
Pedro –

Thanks for the continued conversation.

So let me be a bit more specific about my thinking about moving from specific to generic.  In the knowledge management world we acknowledge that you can’t retain the context of the knowledge and make it explicit — thus removing context.  I can write a book about riding a bike but it will necessarily be missing something.  Of course, it may be that I can write a book about riding a bike that’s effective at teaching people who’ve never ridden a bike how to instantly ride one.  However, I don’t want to board a plane where the pilot only learned from a book.

You can push on the analogy — but the fundamental point remains.  If you remove context you necessarily strip knowledge of something and sometimes that something is super important.  I see the same concern here about increasing levels of abstraction.

Again, at an expert/algorithmic level — you’re spot on.  This is what you have to do, however, that doesn’t make it easier for the client to understand.    I dare you to find two business analysts who can articulate what ontology even means.

When I work with experts I must use one set of language for precision because when I don’t they don’t like that I’m speaking too loosely.  Conversely, if I try to use the very same language with apprentices, they’ll not even understand what I’m saying.  Thus even the language we use is contextual.

This is one of the classic search problems that we’ve been struggling with for decades.  Words are not meaning and the words an expert uses aren’t the words that the general public uses.

Rob

——————————
Robert Bogue
President
Thor Projects LLC
——————————

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.