What's best practice regarding style guides/prototypes/HMI guidelines/process for huge systems in huge corporations?

1 Oct 2010 - 5:43am
2 years ago
4 replies
996 reads
Andreas Absér
2007

Let's say (hypothetically) you're working as an HFE-specialist for a major corporation developing huge situational awareness/command and control systems for many countries. The process for HFE/ID/UX is substandard and the interfaces are often put together by the programmers. 

Now what if you could decide how everything will work instead?  What would you do, what standards would you have the company adhere to? What would the processes you design look like? What key documents would be produced?

OK, big question. But where to start?

Comments

1 Oct 2010 - 8:18am
smitty777
2010

Hi Andreas, 

I've been in this exact situation before.  It's a pretty involved discussion for this forum - feel free to ping me if you want to discuss offline. 

Thanks, 

Bill

1 Oct 2010 - 11:05am
herbert68
2010

Hi Bill,

Can you you please keep me in the loop as well on this conversation?

Thank you, -Herbert

On Oct 1, 2010, at 10:15 AM, smitty777 wrote:

> Hi Andreas, > > I've been in this exact situation before. It's a pretty involved discussion for this forum - feel free to ping me if you want to discuss offline. > > Thanks, > > Bill > >

1 Oct 2010 - 8:05pm
llschertler
2008

Me as well?

Laura L. Schertler

"The power of the Web is in it's universality. Access by everyone regardless of disability is an essential aspect."

~ Tim Berners-Lee


On Fri, Oct 1, 2010 at 5:21 PM, herbert68 <herbert@reiningers.com> wrote:

Hi Bill,

Can you you please keep me in the loop as well on this conversation?

Thank you,
-Herbert

On Oct 1, 2010, at 10:15 AM, smitty777 wrote:

> Hi Andreas,
>
> I've been in this exact situation before. It's a pretty involved discussion for this forum - feel free to ping me if you want to discuss offline.
>
> Thanks,
>
> Bill
>
>

4 Oct 2010 - 7:20am
smitty777
2010

OK, OK... apologies to all.  I didn't realize there might be so much interest in this topic.  I was also hoping to hear back from Andreas, as there might be some issues that are particular to his program that might need to be addressed.   In the absence of feedback from him, I'll give it my best shot. 

There are a couple of things that stick out from the original post to me - especially the fact that he mentions that 1) he's attempting to develop a UI process while at the same time that 2) the screens have already been developed.  My concern is that he is either being pulled into the last phases of a project where the design is already complete or that he is being brought in as a "fixer". Either case is not good, espcially in the case of complex C2 systems.  Establishing a UI process mid-stream would be extremely difficult in this case, since the design roles might already be entrenched.  

Let's assume the best case scenario, that he's starting from scratch and everyone is listening attentively while he rolls out his shiny new process.  The basic design process of wireframing/ usability testing/ prototyping should form a good backbone for the process.  However, there are a lot of other factors to keep in mind as you scale up from a website to a complex C2 system (I'm using an ATC application as an example, since I don't know for sure):

  • Safety: is it an air traffic control system?  Will you be managing a crowded airspace?  If so, what are the national safety standards? 
  • Timelines: is it a time critical application?  What are the threats? Might you have to incorporate rules of engagement or other conops? 
  • Interantional Issues:  You mentioned multiple countries - do the airspace rules change from country to country?  Are there language differences.  Are there national conops differences?
  • Etc, etc:  This list could be endless - there are a million other issues that are specific to each application you need to consider. 
The most important advice I can give you is make sure you include the end users in your design and usability testing as much as possible.  I cannot overstate this enough,and it never ceases to amaze me how often this is overlooked.  Get involved, and know the job of the operators as well or better than they do. 
As far as documentation, at a minimum: 
  • Process doc: Document your process.  Be as thorough as possible.  Keep it flexible - know what pieces you can take out without breaking it. 
  • Standards: There are usually standards out there for this type of thing.  For example, the US military uses the well known MIL-STD 2525 for icons.  Is there an existing set of standards?  You should hope so, as creating these from scratch are pretty expensive and time consuming. 
  • Styleguide: These document pretty detailed interactions.  Some think these are a waste of time, but I would think this is important due to the international nature of your app.  
  • Test Proposals/Results
Hope this helps.  It's pretty hard to go into too much more detail than that without knowing the specifics of your situation.  One last thing - if you are starting from scratch, there are some companies that have an excellent out-of-the-box capability. For example, I've worked with Gallium in the past (http://www.gallium.com/), and I know they offer an extremely good starting point for C2 system. 
Hope this helps, 
Bill

 

 

Syndicate content Get the feed