<< Page 1

Ideally this article could do with a worked example throughout the text. I may republsih again later working in just such a paper prototype example.

Steps Involved in running team UI Modelling

1. Define the scope

It is important to define the scope of the session. Make a statement of purpose, not more than 25 words. Use this statement when working with management to select the team. It is important to keep the focus on the scope, this will ensure that you move forward and get some results.

2. Identify Requirements Documents

With the help of the Domain Expert (or several) select documents which cover the intended scope. These could be

• Functional Specs
• Use Cases
• User Interviews
• User Task Analysis Results
• Rapid Anthropology Study
• Time and Motion Study
• Data Analysis
• Workflow Analysis
• Others

It is important to overlap the documents just larger than the defined scope. This way anything external to the scope which might interfere with the results may get considered. Pay particular to scoping on a single business decision. Consider overlapping the scope to include several decisions over time, or several decisions at the same time. [ Reference: User Interface Analysis, Anderson, 1999. ]

3. Estimate the size of the scope

Make an assessment of the size of the scope, determine how much of the scope might be covered in a single team session, calculate time involved in follow-up work such as documentation and prototyping. Assess the stability of the requirement within the scope. Allow extra time where the requirement is unstable. There is likely to be slower progress and recourse to some arbitration where issues cannot be resolved.

As a rough guide, I have often managed to achieve two or three full screens in basic layout form from a single 1 day session. This would include the basic shape and data to be displayed, the basic outline of behaviour and navigation and a brief rather than comprehensive pass through the detailed data.

These results correlate closely with those reported by Jared Spool [Spool 99] in his newsletter recently when he claimed that a half decent prototype is possible in 12 hours with users. Assuming 4 good hours per day, that would be 3 days.

In practice, I find that it takes another day or more to fully document the sessions. After a session is complete, there should be a series of sketches and a set of scibed notes. It will take time to turn this into a detailed and organised set of documentation. You may also wish to produce a prototype.

So using the Domain Experts guidance, use her knowledge of the scope and assess the full size of the effort involved in modelling and documenting the User Interface.

4. Identify the Objective and Expected Outcome

Deliverables are important. If you do not document the output from the modelling sessions then you have wasted everyone's time purely for the benefit of your own understanding. As mentioned in step 3, time will need to be set aside to produce a set of deliverables. Drawup a list of what you intend to deliver. For example

• a set of UI Model drawings, cross referenced back to requirements and/or features
• a set of high fidelity screen images
• a runnable prototype
• a set of storyboards for scenarios or Use Cases
• a presentation package for management or a wider group of Users or Developers
• a behavioural description for each drawing
• a list of data fields for each drawing, perhaps cross referenced to requirement or source of data e.g. PD Model Class, User Input, SI source specifying which interface.

I call this collection of deliverables a High Level Design (HLD). HLD is a topic for a future article at uidesign.net.

5. Pick the team

Together with a Domain Expert and a manager from the IT/Supplier side and a manager from the User/Customer side, select the team members. The managers involved must be sufficiently high level to enforce the team selection decision. It is vital that the correct Users are involved from the beginning, otherwise things may get missed which would be important later, causing a UAT Defect for example.

If you cannot get all the Users you need together at the beginning then proceed as best you can and ensure that you review the output with the others later.

The most important member of the team from the IT side is the scribe. You must pick a highly experienced UI Designer, Usability expert or knowledgable UI Developer, who in turn must be willing and able to do the scribing job. Without a good scribe you will lose vital detail from the discussions. This costs money and will result in dissatisfaction from the User side, who may feel that you are wasting their time as you never follow up on their suggestions.

6. Get proper management buy-in

Ensure that managers support and understand what is happening and why. If possible, define an arbitration panel and system in advance. Report unresolved issues from team sessions to higher management who may refer them to the arbitration panel. This is particularly important where business process re-engineering is being done in parallel with the system development.

7. Schedule Team Sessions

Use the time estimate from step 3. to create a schedule. Liaise with the selected team to get possible diary dates. Set the dates well in advance and notify all the members, giving an outline of what is to be discussed. Nearer the time pass out a more detailed agenda.

7. (a) Plan and Schedule Breaks

Remember that people are human, they will need time to for breaks. In addition to basic comfort and snacking, they have a business and a life to run.

7. (b) Stagger sessions to allow time for other work

You will find the Users are much more agreeable to help, if you can work around their schedule. If the business that they do is particularly busy at a certain time of day or day of the week, then avoid that time. Schedule the meetings at times when the Users can relax and not worry too much about day-to-day stuff.

The "dead-time" when Users are away doing their own business will give the UI Design team an opportunity to catch up on documenting what has happened and reporting back to management. It is particularly vital that contentious issued are highlighted quickly to management and possibly to the arbitration panel.

7. (c) Pick a neutral location

Psychologically a neutral location is best. It is least threatening or intimidating. At least initially there will be a "them and us" situation between the Users and the IT people. A neutral location helps to allieviate such problems. A Conference Suite is ideal for such occassions. Pick one which is conveniently located for Users so that they can get to and from their desks quickly.

7. (d) Provide buffer time at beginning and end of the day

To emphasise 7. (a), remember that doing business is the prime concern of the Users. Never start sessions too early or run them too late into the afternoon. The Users need time to sort out the mail in the morning and deal with any overnight issues. They also need time at the end of the day to catch up with events.

If you make it clear when informing team members that sessions will be scheduled in the fashion described here, you will find that they are much more willing to help you. If you work around their important schedule, they will see and appreciate that you understand their business and want to help.

8. Acquire the necessary Collateral

Before the session, ensure that you have the correct materials gathered. The following list is fairly comprehensive. Pick and choose what works best for the way you want to work. If all you're doing is low fidelity drawings then you'll get away with the first 6 or 7 items only.

• Requirements Documents, 1 copy per person, covering the scope of the session and the slightly beyond the boundaries of the scope. Not the entire requirements, this may lead to focus being lost.
• Paper - A4/Letter plain, lots of it
• Pencils - the mechanical/propelling type may be best but any sort will do - remember erasers too
• Flip Chart & Paper plus masking tape to stick sheets up on the wall
• Marker Pens (as many colours as possible, this is screen design)
• White Board
• White Board Marker Pens
• Laptop Computer - must have a large active matrix display, pre-loaded with any software tools which may be helpful, internet/intranet access could be useful
• Colour Printer - this is not an option for UI design. The benefit vs cost is very easy to justify. Once you've experienced printing high fidelity prototype screens in colour, the whole team will never go back to black and white again
• (Optional) Video Projector - capable of projecting the laptop screen onto a bigger area
• (Optional) Artists Fancy Paper - in thick card quality and in many colours. Use it to draw better quality low fidelity models
• (Optional) Artists spray-on rubber adhesive. Take a lesson from the advertising agency business. They use this adhesive to provide storyboard mock-ups for advertising. This allows you to stick-on / peel-off card models of windows, dialogs and panels. Its very powerful for low fidelity prototyping of scenarios. or early usability testing.

9. Starting a Team Session

At this point, some experience / training as a facilitator is helpful. There are some good books e.g. "Managers as facilitators" - A practical guide to getting work done in a changing workplace", Weaver & Farrell, Berrett & Koehler, 1997, or the Coad Letter, "Lessons learned from Fred". Its important to have strong facilitator skills, in order to get effective work done in the meeting. Some formal training might help, or alternatively hire a professional facilitator, if you're not confident yourself.

A professional facilitator is a good neutral person who won't be seen to advocate one point of view over another. This is important. Even if you are facilitating yourself, you must strive to be seen as neutral. Even if you are directing the session towards a particular goal or outcome - a particular style of design - you must introduce these ideas subtley and not appear to be bullying the team or dictating the route.

A good facilitator will open the meeting by stating the following

• Purpose of the meeting
• Objective
  • ideally you should be looking for sufficient design shape as a model plus exploration of sufficient key scenarios and data areas to have confidence that you can go back to base and fully develop a complete set of screens and storyboards to meet the requirement. "Confidence" is the key word.
• Identifying the deliverables
• Introduce of each team member, if this is necessary. Or ask each member to introduce themselves.
• Set the agenda and describe any breaks e.g. lunch interval, which you have planned in advance
• Describe the tools that you are going to use
• Try to set "Norms" for the meeting
  • 1 talks - All listen
  • Respect others point of view
  • Its OK to disagree
  • etc

This opening section is intended to set a professional tone, establish respect for the facilitator and ensure that everyone knows what is going to happen next. When people are aware of what to expect and what is expected of them then they are more likely to respond positively and help to achieve the required goals.

10. Expect Tension and Disagreement

UI Modelling Sessions are not likely to be harmonious! There are many possible sources of tension and disagreement

• Technical Capability vs Requirement conflict
• Cost vs Benefit conflict
• Ill defined requirement
• Customer/User Politics - beware Users with their own agenda
  • their department was not consulted when the requirement was written
  • their requirements were taken out-of-scope and they want them back
  • they are attached to a particular vendor or product e.g. Microsoft Windows NT or Lotus Notes
  • they love the existing system though everyone else hates it
  • they stand to be replaced by the new system and want to be obstructive
• Conflict between ranks and different responsibility holders

The UI Designer is in a difficult position. As facilitator it is important to stay neutral, to protect ideas and give everyone a say, as UI Designer it is important to simplify the design and manage the scope of requirements and the expectations of the Users.

Don't be afraid to be firm with someone. If something isn't going to reach a conclusion then put it aside. Tell the team that you want to put it aside and come back to it later. Getting sufficient agreement usually isn't difficult.

Call a break. Its always a good way to alieviate tension.

Finally, if someone is repeatedly disruptive and is preventing you from going forward then ask management to move them off the team.

11. Using Strategies to discover UI Model Shape

Using the User Interface Analysis strategies, [Anderson 99], start to work through the requirement material. Use the results from the strategies to start forming shape. Use established patterns and re-use patterns which you have used elsewhere in the design. Guide the session. Look to achieve a shape which will fit within desired look and feel, application or OS environment, as well as be consistent with other parts of the system.

This process is analagous to early Object Modelling when we're looking for classes, basic model shape and class relationships. However, this time we are doing it with screens, windows, panels, tabs, widgets and menus.

Using Flip Chart or White Board, draw up the emerging shapes. Feel free to draw some alternative shapes.

Using Strategies and Patterns is a big area and the subject of several other papers. Basic Patterns for User Interface is still a very new area. It has not developed to anything like the maturity of the patterns movement in Object Modelling. For example, Peter Coad's new book, Java Modeling in Color with UML: enterprise components and process, with Brian Lefebvre and Jeff De Luca, presents a series of basic model shapes for many line of business applications across numerous business sectors. At this time there is no such analagous work for User Interface.

Searching for the correct UI Shape to solve a business problem, is still very much a start from basic principles problem.

12. Preserve Ideas

Don't be afraid to draw more than one shape. Stick the others on the wall using the masking tape so that everyone can see the other versions. Take side notes when someone comes up with another idea which you don't have time for. Ensure that they know that you have recognised the idea. Perhaps have a list of side issues on a special sheet on the wall. Come back to it later.

13. Consult the Expert UI Developer

Sometimes you will hit on a problem which isn't easily solved or no known pattern comes to mind. You may need to innovate to solve the problem. This is the point where your expert UI Developer is needed.

Take guidance from the UI Developer when a request or suggestion is made which may or may not be technically possible e.g. Can we split a table column into two sub-columns? The answer may be environment dependent. Its important not to commit to anything that you're not confident you can deliver.

14. Expect suggestions from the Expert UI Developer

Expert UI Developers are by their very nature "Widget creators", so expect them to suggest technologically led ideas which will help with model shape or behaviour. Don't always accept these ideas, simply because they are technically possible. It is very easy to get carried away with "Widget Evolution", next thing you know, you have doubled the number of "widget species" in your design and extended the learning and recognition process for the User.

Don't simply reject such ideas either. Its better to protect them and agree to examine it more thoroughly outside the meeting before deciding whether a new Widget is in or out.

If your UI Developer isn't making any suggestions then you selected the wrong person for the team. Move them off and get another one with more imagination.

15. Break into smaller groups

Breaking the large team into smaller working groups is a useful ploy. There are two key times when this is necessary:

(a) When the session seems to be blocking, or

(b)Two or three similar looking/sounding areas need to be developed and time is limited

Split the team into two or three smaller groups. Put a UI person in each group. If there are three groups, then put the facilitator in one group, the scribe in another group and the UI Developer in the third. If there are only two groups then the facilitator should form a third group of one, or simply use the opportunity to take a break. Facilitating these sessions is tiring.

Timebox the group session, with 5 minutes to go, ask if the groups need more time. Schedule a break afterward, before the group results are presented.

The facilitator can use the small group session as a chance to wonder around and listen to the issues being discussed. Make notes. Come back to them later.

If you use small groups regularly then ensure that the members are shuffled regularly. This ensures that fresh ideas are flushed out and that one of two dominant personalities don't over power a quieter one who has good ideas. Working in small groups will help to bond the team, breaking down barriers between the IT side and the User side ( Supplier vs Customer ). Better results will be achieved once the team starts to work together as a single unit rather than separate cliques.

16. Presenting Group Results

Ask a group member to present the group results to the whole team. Try to ensure that group members take it in turns to present. Ensure that other group members listen and understand the ideas from the group presenting. Allow questions to be asked after the presentation.

Generally, the group should have a series of sketches or storyboard. Perhaps simply a layout for a problem or a series of navigation selections. Ensure that they detail which part of the requirement they were addressing with the solution and ask them to detail any problems which they felt were unresolved.

Work around each group in turn, until all have presented

17. Merging Group Designs

From scenario (a) there was a team-wide block on one problem. Now 3 solutions are available (hopefully). The separate results will generally cover slightly different areas and perhaps one team will have solved a problem that the others overlooked. Look for shapes and behaviour which solve the problem whilst fitting with existing look and feel goals - for consistency - or for the most minimal design - or the most usable. As facilitator, try to pick the best from each design and draw up a best fit composite result. There may be issues to trade off between designs. Some designs may simply be poor. The audience will tend to recognise this when a clearly better one is on offer. Draw up the composite design and work to achieve buy-in from the whole group.

From scenario (b) there were 3 potentially similar areas to be modelled. Perhaps the data was different for a specific type but the overall classification of the data object was similar e.g. How to display the specifications of Cars, Trucks and Buses. So take each design and try to draw a merged outline design which brings consistency across the variants e.g. Ensure that Engine Capacity is displayed in the same location for each model. Try to use this opportunity to reduce development complexity and promote re-use of code by identifying identical areas within each model.

18. Walking through Scenarios

Now that you have some shape, with the Users and Domain guidance pick a Feature / set of Features / Use Case / Set of Use Cases / Scenario - single path through a Use Case / User Task or Function, and walk through the design storyboarding the operation. This is where the behaviour is discovered.

You should find that several screen models will be visited as the scenario is run. You may find that screen models are missing and more shape is needed. So go back to step 11 and iterate through again.

You should find that you are identifying buttons which need to be pressed, selections on tables, pop-up dialogues, questions which need user input, decision points, lists of options, data to be highlighted. As you explore this, the shape may be changing slightly or even largely. You may find that the existing shape doesn't work and you have to start again. Don't be afraid to iterate. Simply keep the existing version. Stick it on the wall and draw up a new one.

Don't be afraid to split into small groups to treble the effort. Perhaps even run 3 scenarios at once. Consider this process as analogous to Scenario Views in Object Modelling [Coad - insert appropriate reference].

19. Ensuring User Coverage

The Domain Analysts or Users will have guided you to pick the scenarios to ensure Domain / Requirement coverage. It is the UI Designers job to ensure that User Task and Job Function coverage is also complete. For each Job Function represented in the User group within the UI Modelling Team, walkthrough the screen model shape and behaviour. Does it meet their needs? Do the same for each identified User Task which has relevance to the requirement scope in question. Does the data on the screen facilitate the completion of the task? Ensure that different levels in the chain of responsibility are covered e.g. worker, line manager, functional/division manager and top management, if appropriate.

The data obtained from Strategies Analysis will help you to order and prioritise testing and checking the coverage. When a particular task is well down the priority list, you must ask yourself, "Is it worth changing the shape to accommodate this requirement?" Perhaps not. Perhaps these less often used features can be hidden away.

20. Ensuring Data Coverage

Now using Domain and User guidance pick some key data items from the requirement. Revisit the UI Model and place the data items in each of the screen drawings, add fields, add columns to tables, rows to tables, determine if fields are User entered or Display only and under which circumstances - point in workflow/process, task, role of User, time in life cycle etc. Identify the sources of data. This may be written in the requirement already, so establish the cross reference.

There may now be too much data on some of the models. They may no longer fit on a screen. The shape may need to change. Use User Interface Analysis strategies [Anderson 99] to explore the requirement with the Users. Try to simplify the design. Try to reduce the scope or scope down to the bear essentials. Accept that the shape must change, if the data requirement is real. Don't be afraid to break into small groups to discuss this.

21. Summarise the results

It is vital that some quality time is spent at the end of a daily session so that all the members can reflect on what has been achieved. This is particularly important in the early stages of team development - the forming and storming stages.

At the end of the session

• Walkthrough and summarise what has been achieved. It ought to be obvious. There should be a lot of drawings on the wall.
• Recognise the scope of the requirement which has been covered
• Identify what has still to be covered in a future session - make an agenda for the next session
• Identify areas where you are confident the UI Designers can proceed alone using the results from the session and without further involvement of the whole team e.g. a shape for Traded counters will probably work for Stocks, Shares, Unit Trusts, Bonds, etc..
• Identify the list of issues to be reported to management

22. Minute the meeting

Have the scribe write-up the scribbled notes and formally publish as minutes. It is vital that this is done while the session is fresh in everyone's memory. Pass the minutes round amongst the IT team for further comments before you publish them. Report the outstanding issues to management and attend any arbitration sessions as required.

23. High Fidelity Prototype Screens

For the most part, low fidelity prototyping is sufficient. It is a cheap, fast process. For some places in the system I believe that a higher fidelity prototype is important. There are two possible stages. A proper screen drawing, mocked up in a paint package or a full blown working prototype.

High Fidelity Drawings

Draw up screen models into full mock-ups using a paint package for the target system. You will need a standard set of widget graphics which can be pasted and manipulated to recreate the models. When the screen was under Shape Pressure, use this process to verify that everything fits. When the screen is under Business Pressure, develop enough screens to provide an animated storyboard or walkthrough to show the flow.

Full Blown Prototype

A lot has been written about prototyping code which doesn't need repeating here. You can consider using a 4GL style tool, a RAD environment, a GUI Toolkit like Zapp, or a simple but effective language tool such as Visual Basic, or Java using off-the-peg Beans. I think that this is fine if the resultant prototype will look very similar to the deliverable. Personally, I prefer to prototype on the delivery environment.

My view is that you take a good programmer with "hacker" tendencies and let them loose on the design. Ask them to cut corners and ignore quality. You aren't going to re-use the code. You aren't going to review the code. You are going to throw it away. If you have aspirations to save budget by re-using the prototype then you are storing up trouble for later.

24. Validate the Design with the whole Team

Go back to a full team session with the results and run through some more scenarios. Get full buy-in where possible.

25. Document the Design

Using what has been learned from the whole process, produce and publish the full set of deliverables which you defined in step [iv].

26. Formal Design Review

A formal Design Review is important. Publish the designs and arrange for a review a few days later. Involve the original team and perhaps others from Development, Test and Publications. You may want to split the review into two. A Customer review and an Internal IT Review.

Acknowledgments

Thanks to Alan Laird at likk.net and Jeff de Luca for reviewing this material. My thanks to my colleagues at a major international bank in south east asia who spent the last 18 months testing this procedure and helping me to refine it. Special thanks to James Mitchell (my scribe) and James Tan (my Widget man) for their efforts during these team modelling sessions.

Also to Peter Coad who pushed me gently and just hard enough to write this article. This work is broadly based on Peter's process for Object Modeling and mentoring with a team. The process works for OO and it works for UI Design. Peter's enthusiasm is infectious and his encouragement was much appreciated.

Reference

[Anderson 99] User Interface Analysis, uidesign.net, Feb 1999, http://www.uidesign.net/UIA1.html

[Spool 99] User Interface Engineering Newsletter, Paper Prototyping, Jan 1999, http://www.uie.com

[Coad 99] Java Modeling in Color with UML: Enterprise Components and Process, Coad, Lefebrve & De Luca, Yourdon Press, 1999

http://www.oi.com/jm_book.htm

[Arlov 97] GUI Design for Dummies, Laura Arlov, 1997, IDG Books

<< Page 1