UI Personas
An important part of designing an user interface (UI) or user experience (UX) is to know who we are designing for. One of the tools for this in interaction design is to develop some personas. These are fictional people who embody all the goals of actual users of the system. So for re-designing the UI for CruiseControl.NET I have put some personas together.
Note: these are not true personas as they are not based on research. Instead they are based on my understanding of a typical user; so they will not be as effective as true personas.
Patrick
37 year old male
Patrick is the systems administrator in a team of 12 at a small software development house called Rainbow Interactions. His job involves implementing and improving processes within the team. He directly reports to the CEO of Rainbow Interactions and often works directly with their customers. As such he has a very busy schedule and likes his time to be as streamlined as possible.
Outside of work Patrick is married with three children. As he spends a lot of time at work during the week he refuses to work during the week-ends so he can spend time with his children. He enjoys walking in the wilderness and so will often go away during the week-ends; which also means that work cannot contact him with any “emergencies”.
Patrick is involved in the initial setup of every project and then helps the other developers as required. He is also involved in cleaning up after each project has completed. His work varies from day to day depending on where in the project cycle the team is at. At the beginning of the project he makes time for setting up everything required for the project, including continuous integration (CI). During the project he will help the developers trouble shoot problems and even occasionally write code. Finally at the end of the project he archives all the work for the client. He might also go to the client’s site to help transfer the work over if necessary.
As part of their process for working on client projects they always set up a new CI process. Each process has a common core with the basic functionality (e.g. retrieve latest changes, compile the code, etc.) but they can all be customised depending on the clients’ needs. While Patrick sees this as an important part of his job he doesn’t have much time that he can spend on setting up CI processes. Instead he just comes in, copies the default template and then adds in the modifications as required. As different developers can be working on different projects, and sometimes the clients also have access, he likes to lock down the processes so only the relevant people can have access.
Patrick only helps with trouble shooting if there is a problem that the developers cannot solve themselves. His first question when they come to him for help is to ask what they have already done. If they have not tried anything (e.g. don’t know where to start) or they have missed something then he will advise them where to look. If it is a problem outside of their ability or capacities then he will get involved. These are normally problems on the CI servers (maybe bad configuration, maybe server issues, etc.) The first place he always looks is the server logs and from here he will trace the problem. As such he likes to see as much information as possible (which might include elevating the logging level to get additional information.)
To archive a project all he does is select the project and the destination and then starts the process. This copies everything to the destination and removes the process from the server. Later on he can restore the process or he can install it on another CI server if needed.
Michelle
26 year old female
Michelle is a developer at Rainbow Interactions. She has been working on a project for their most important client – Here and How Shipping – for the past five years and has recently become the lead developer for their system. Since Here and Now Shipping has been with Rainbow Interactions for several years now they have a well-defined CI process. However from time to time things change and the process needs some improvements (for example they learnt about code coverage recently and wanted that included.)
Michelle’s day-to-day job is very simple – she takes the list of requirements she gets given from the business analyst at Here and Now Shipping and works with her time to implement them as quickly as possible. Most days this involves writing code, sometimes testing, sometimes bug fixing. No matter what she is doing though she is always running short of time and will often stay late at work, with the occasional week-end day as well.
She just expects the CI process to work – when she (or any of the other developers) checks in code for Here and Now Shipping’s system it should automatically build and then notify her of any problems. If the build goes fine she doesn’t care (although sometimes she might look at it to just touch base” but it breaks she wants to know as soon as possible. When the build does break she wants as much information on why it has broken as possible so she can either fix things or chase down the person who broke it. The last thing she wants to do is bother Patrick as he is often grumpy if developers bother him without a “good” reason.
Her primary development environment is Visual Studio, but she also accesses build information remotely via the internet. She likes to see all the information possible on the build (number of changes, which unit tests were run and how long it took, the amount of coverage, any coding rule exceptions, etc.) She also needs to start and stop the process, trigger builds and modify the configuration if necessary. Basically she needs to do everything with the CI process for Here and Now Shipping. But conversely she doesn’t care about any of the other clients Rainbow Interactions works with.
Of these two personas I’d put Michelle as the primary persona as she is the main user of the system. However Patrick would have a different set of interaction goals so he would probably be another primary, although not as important as Michelle.
In my next post I’ll look at some interaction goals these two personas have and maybe some scenarios. With these in place we can start to look at how we can design the interaction process for our users. 
Stay tuned…
