UI Goals: Patrick
Continuing with the UI design we come to Patrick’s goals. As I stated in the personas (read them here) I’m not really sure that Patrick is a primary persona but as he is probably going to need a separate interface for his work I’m treat him as a primary persona with a complete set of goals.
Simple and easy to use
Since working with CruiseControl.NET is only a small part of Patrick’s job he does not want to have to spend a lot of time learning the system. The interface should be intuitive to use, allow him fix any mistakes without them becoming serious problems and only require a minimum of work. He should also be able to setup “templates” for different projects that can be quickly applied.
Configure the entire system
Patrick should be able to configure everything in the system from a single console. He should not need to swap between different programs to set things up. This includes setting up, configuring and upgrading multiple different build servers. The “everything” that he needs to configure includes the different build projects, users and their security access, servers, etc.
View complete diagnostic information on the entire system
When Patrick is trouble shooting he should be able to see exactly what has happened if anything fails. When an integration fails he needs to know which project failed, which step in the integration and why it failed. Since he is only called in for fixing the problems that developers can’t (since he growls at them if they bug him) he needs to see more than just want the developers see. This information includes details about the servers (memory, CPU usage, available disk space), any other processes that were running (and might have caused interference), etc. Of course the information should be in a format that makes it easy for him to spot the cause of the problem quickly!
Automated monitoring
Given that Patrick prefers not to be bothered by developers he would much rather be notified of problems by the system directly rather than the developers. This means he can fix things before they come to him, which in turn makes the developers even more impressed with his abilities. As such he wants the system to notify him when certain parameters are exceeded. As he already monitors other systems and servers for Rainbow Interactions he wants the notifications for CruiseControl.NET to appear in his monitoring tool rather than needing a separate tool.
Comparing Patrick’s goals with Michelle’s we see that they both have a different focus. Patrick prefers an in-and-out approach – get in, do his tasks and get out – as quickly as possible. He also does not want to become an expert in the system so it needs to be as easy to use as possible. In contrast Michelle is more of a regular user. She is happy to spend some time to become familiar with the system if it will make things easier for her in the long run. They also both have some common features: it should work within their current tools, it should notify them when things go wrong and it should provide them access to everything they need in a single location (although for Michelle this will be two different locations.)
Hopefully this is starting to sound like an interesting challenge 
Next step, time to put together some context scenarios to provide some generic detail on when and how they will approach their different tasks. Stay tuned…
