Page 2 >>

This month I follow on from the User Interface Analysis paper with a paper describing a process for modelling a UI Design. This process would involve working through the UI Strategies from last month and applying, interaction design patterns or navigation models to that analysis and working toward a paper (or other ) prototype for the UI. Again this paper very much represents a work in progress and I will gladly accept your feedback on it and pointers to other work in this area. I have tried to include some references at the end but I am sure that it is nowhere near comprehensive.

I have split the paper into 2 pages. The first covers the groundwork for why UI Modelling in teams is such a strong process. The second page details the process as a series of procedural steps.

Introduction

The goal of a System or UI Designer must be to provide a system which is functional whilst being minimal. What do we mean by minimal? Minimal means that everything that needs to be there is indeed there and nothing more. This is the goal of both the Object Modeller and the UI Designer. The Object Modeller wants to put the minimum number of classes into the model, with the minimum number of references, and the minimum number of methods, whilst maximising re-use and facilitating future extensibility. The UI Designer seeks to do the same with the external face of the system, the Graphical Interface and User Interaction. It, too, should be minimal. What does that mean? It means the minimum number of screens which meet the functional requirement, with the minimal amount of interaction. The computer should facilitate the User to complete a task, not get in the way. This is most likely with a minimal design. As a side effect of such a design, the UI Designer would hope to provide a more Usable system.

Usability, however, is more than just a minimal design. It is understanding what needs to go together in a system to simplify a User task and allow the User the minimal interference in order to achieve their goal. Understanding these things is often impossible from a functional specification and requires other techniques. There are passive techniques such as User Interviewing and User Task Analysis. This provides the UI Designer with a set of data which can be used to influence the design. There is, however, an alternative. An active technique which involves, Users and Domain people. A technique which has already been regularly employed successfully with Object Modelling - Facilitated Team Design Sessions.

This paper describes a process for running Facilitated Team UI Design Sessions, in an analagous fashion to Object Modelling Sessions. The objective of such sessions, is to produce a model for the User Interface - a prototype, whether it be a paper drawn storyboard prototype or an actual runnable high fidelity prototype.

Advantage of Team Design Sessions

Why use a team? After all, you are the UI Designer, are you not? Why do you need any help? Are you incapable of producing the design on your own?

Clearly, a good UI designer is someone who understands implicitly the process involved in using software and displaying information. The Users however, are the ones who understand the domain and know what they need a system to do. As in every walk of life, people tend to specialise and develop a niche where they are best suited. You are unlikely to come across a single individual who knows the business inside and out, both breadth and depth. Clearly a number of individuals are needed to get the full picture.

The other big advantage of working publicly in a team, is the ownership of the design. If you gather the detail on your own then produce a design as a separate process, it will be your design. The Users are likely to question it. "Why haven't you used our design?" This is particularly true, if the requirement was detailed as Use Cases. The way around this problem is to deliver a team design. It won't be your design, it will be their design. You merely facilitated its development. This team ownership is key to later acceptance.

The downside of such a team design is that you won't get the credit for it and you will here things like - "Don't know why we needed that guy. We did the design ourself." Smile gently to yourself, for you have done your job well. :-)

Fitting into the larger System Design Process

In practice, it is always best to do this work early. Ideally you would do this during the writing of the functional requirement. If you are writing a requirement using Use Cases then you need User Interaction diagrams. If your Use Cases are written by inexperienced UI Designers or people with no UI understanding then it is likely that you will deliver a requirement which is unworkable in practice or simply too poor from a Usability standpoint that you cannot implement it. This immediately spells trouble for the design and development process not to mention test. If the Use Cases describe a "theoretical" User Interface and what you actually build later is different, how then do you test against the requirement? A difficult problem for test managers the world over. No it is better to solve the problem early and design the UI as part of the requirement and get it into the Use Cases early - before Object Modelling.

Now back to the real world.

The truth will be that you will have requirements already, perhaps as Use Cases. You may already have an Object Model and you may already have code in construction. You need to get a UI Design together and you need to validate the design decisions made so far. The best way by far to do this, is to get the Users directly involved in the User Interface Design process. Use the output from this to feedback into the Analysis and Design of the system and iterate. You will get a better cleaner system in the end.

Here's how I go about it...

Team Members

So who should be one the team? and how do you go about forming the team?

Its important to have the backing of top management. In practice this is easy. The top management will probably be pressing for maximum User involvement. As UI Designer you can play on this and present your team proposal. Work with line management to select the suitable players. You should get together with the line management from both the IT/Vendor and Business/Customer side and pick the team. The roles involved will be as follows:-

Facilitator

Who: a UI Design Guru / Designer / Usability Expert / Experienced UI Developer / Professional Facilitator

Role: to run and guide each team session, to maintain control of the meeting, control the agenda, focus the discussion, ensure everyone gets to have a say, protect ideas, no matter how unusual

Scribe

Who: a Qualified/Experienced UI Designer/Developer / Usability Expert

Role: to ensure that the full scope of discussion is written down, to produce minutes of the meeting

Technical Consultant

Who: a UI Library Expert / Experienced Developer / Rapid Prototyper / a "GUI Plumber" or "Widget DIY man"

Role: to provide guidance on technical issues, technical guidance and technical suggestions

Domain Expert / Analyst

Who: a Systems Analyst / Business Analyst / Pre-Sales Support Engineer

Role: to provide a thorough understanding of whole requirement, to help maintain scope focus in the discussion, to prevent feature creep.

Users

Who: a representative of each job role / a respresentative of each responsibility level

Role: to provide feedback on the requirement, suggested designs and to give insight into the real job, processes and functions

When selecting the Users to be involved it is important to select the users according to the scope of the session or series of sessions you intend having. For example, if you are focusing on say a single business area such as marketing, then it makes no sense to involve back office staff.

Strategy for selecting Users

As a broad rule of thumb. If you are looking at the big picture of the whole system, then involve at least one User from each job function. If you are looking at a piece of the system, then involve a collection of Users from each responsibility level for the area being examined.

Page 2 >>