Sure. I'm actually working on a blog article about AQU, as I like to call it, but here's a lowdown for you:

In the first step, I'm building a set of ID values that I want to query against. a Set is a special type of collection that will store each value only once. That means that given:

List<Integer> a = new List<Integer> { 1, 1, 2, 3, 5 };

Adding them to a Set results in:

Set<Integer> b = new Set<Integer>();
b.addAll(a);
System.debug(b); // b = {1, 2, 3, 5}

Using this knowledge, I can construct a unique list of ID values I'd like to locate by query using the most optimal set of ID values. Since a Map has a key and a value, but I do not yet have the value (which will be your Process_Template__c record), I simply store a placeholder "null" value into the map.

In the second phase, I use the putAll method, which is actually identical to the following code:

for(process_template__c temp:[select id,name,(select id,name,sequence__c,details__c,assign_to__c from process_template_steps__c) from process_template__c where id in :templates.keyset()]) {
  templates.put(temp.id, temp);
}

However, putAll is a system function, and so has a cost of 1 script statement instead of 1 script statement per row in the query, which saves me up to 199 script statements each time this trigger fires. You can only use putAll on maps with a key of Id, and a value of SObject (e.g. an Account SObject). It's a convenient function to grasp, as it can speed execution time.

In the third phase, we loop through the trigger records again. Here's where a map really shines. Without a map, you'd have to resort to the following logic:

Set<Id> templateIds = new Set<Id>();
List<Process_Template__c> templates;

for(Process__c record:Trigger.new) {
  templateIds.add(record.process_template__c);
}

templates = [select ... from process_template__c where id in :templateIds];

for(process__c record:trigger.new) {
  for(process_template__c template:templates) {
    if(record.process_template__c == template.id) {
      // do logic here
      break;
    }
  }
}

A loop within a loop has a maximum script count of X1 times X2 times C, where X1 is the number of elements in the first loop, and X2 is the number of elements in the second loop., and C is the number of statements within the loops Using a map cancels out the cost of X2 (because X2 is now 1), so the entire loop is reduced to a cost of X1 times C. Given 200 templates and 200 process records, you would have up to 40,000 statements executed using nested loops. Even the "break" statement to stop the first loop only reduces the maximum execution to 200 times 100 (20,000) statements, which is 100 times less efficient than using a map. In contrast, the map-based loop will always have a maximum of 200 statements times a constant for number of lines inside.