Involving Operators in HMI Design

If you really want to get the most value from the design process, you need to involve the operators, process engineer(s) and the control engineer(s) at minimum. I agree with the comments that involvement needs to begin early in the process. We follow a process similar to first post, only updated to use more modern tools. We first conduct a training class on HMI design principles, what is good design, what the HMI can look like, how to use the tools etc. Once we have a common understanding of what 'can' be done - operators don't always know that we can sometimes do a lot more with the HMI that what they have now - we start prototyping. Measure twice, cut once approach. Usually we work with the site team to develop the graphic content not just the style (colors, widgets etc). All the prototype graphics are done in Visio which allows revision and approval tracking. We then use a tool to automatically convert the prototypes to the DCS system so the operators can evaluate the graphics for real. All of this can be done well before they need to start using the new graphics.

Usually we have a couple operators that actually do the graphic drawings but we try to get input from everyone. If you get the right operators for the drawing task, give them some guidance, they come up with some incredibly useful graphics. They get to fix many of things that have been bugging them.

So as you can see this is a front loaded design effort which needs to be factored into the project plan.

When I worked for Fischer & Porter's project management group, the easiest projects to implement were when operators were involved in designing graphics. It helped if they got in at the beginning of the project. In the water/wastewater industry, the best projects were when operators helped approve submittals. When start up came, there were no surprises.

The worst case was when operators had no input into graphic design and start up day came and not only did the operators not like the graphics, but their non participation put a sour taste in their mouth for the entire system.

So I agree that letting operators design graphics is a good idea. Having them involved in the beginning of a project helps vendors and plant management guide their ideas into meaningful site standards and efficiencies.

Ken

I tend to agree that operators should the players of the HMI design not just for approval or ideas. HMI providers have to keep the products simple to ensure the people designing the HMI are not just engineers. Operators tend to be more practical and they will design the solution they want to use. Providing them something done by someone else is always an issue even if they have been involved in the definition process. Engineers should focus on application organization and structure but the HMI by itself (faceplates, alarms panels, synoptics, ...) should be the world of the operators.
Advantages:
Better acceptability, quicker time to market, better maintenance (lower cost of ownership)
Risks:
validation of the work done by the operators, but this can be managed without big problems.

Whilst I completely agree that operators should be involved in the design of the graphics I am not so sure about letting them design them on the system itself as rhrib suggests.

First, I think an HMI should be designed before it is implemented. That means sketching them or using a tool (such as ControlDraw) rather than just diving in and hacking out a graphic on the DCS.

Consider also for example where the graphics are 'Unit Relative' so one core graphic is used and instantiated for each of the units to which it applies. This is far a more efficient and object oriented method than each unit having it's own graphic. But it is not so simple and requires a greater understanding than might be expected of an operator.

And in validated environments (eg pharmaceutical) such changes to a system as adding graphics are changes that would need testing and validating, which means among other things that they should be specified before implementing.
Francis
www.controldraw.co.uk

The best situation is, if operators are able to draw new displays directly in DCS graphic environment - static displays are enough. It saves a lot of time and final acceptance of process displays is guaranteed.
Teach the operators how to draw the displays - they will learn possibilities and limits of the visualisation.

I like it. That was a very innovative process.

I also agree, the Operator's need to be part of the process from very early. But managing input from numerous sources can sometimes be very difficult.

As an implementor, and not part of the end users company, I typically cannot approve or disapprove any requests from Operators. Ultimately, one person on the customer's side needs to be the final arbitor. This can be someone from corporate engineering (usually least desirable), plant engineering or operations. Sometimes a Senior Operator is ideal, sometimes not. If this person is too domineering, the other operators stop providing input. If they are too "wishy-washy" the displays get changed repeatedly - and you never reach a consensus. As are many design issues it comes down to a balancing act.

Good post - I hope we get lots of comments.

I agree.

Operators need to be involved from the beginning when the HMI specification is being developed. Also, it is very important to have graphic reviews at different stages of the project if possible.

One last thing. It is important for the operators to be involved in the final software test so they know what will be delivered to site for the commissioning.