Tuesday February 10th, 2015 by Björn Balazs
Last year we teamed up with Intevation to create interfaces and interactions for TrustBridge. TrustBridge is a secure root certificate installer for Windows and Linux, contracted by the German Federal Office for Information Security (BSI). And it is Free Software.
When we joined the project some interfaces were already done. They were mostly used to communicate with the client about the expected functionality. For this article they can be used for a before and after comparison.
Picture 1: Updates of certificates in an early TrustBridge version.
Following we describe the steps we went through to create the UIs and interactions. As time and money budgets were tight (as always) on this project, we had to go through the whole process rapidly. Even though the steps suggest a strong hierarchical order, the work actually is an iterative process. So whenever we discovered something to be missing in the steps before, we simply revisited them.
Step 1: Vision
In order to create stunning experiences it is extremely helpful to first focus on the target that should be reached. Usually this is done through a vision. For TrustBridge we came up with:
TrustBridge makes email and https communication safer by making it so easy and comfortable for the user to install and update a basket of relevant communication certificates, that they will actually do it. This way the BSI comes a little closer to its task to strengthen the IT security with and within the federal authorities.
The problem is that it is hard to get communication certificates officially supported by Microsoft or Mozilla. Especially when you manage your own certificates as a federal authority or company it takes some time (and money) to get this official support. Same is true if you want to revoke your certificate, because it got somehow corrupted.
Currently users have to add and revoke these certificates by hand, but this is a frustrating process with the current systems. So TrustBridge wants to help here and make the management of these certificates easy and reliable – and by this help to make communication more save.
Step 2: Users
With the goal defined, it is helpful to create a picture of who the users of the product will be. Here Personas can be helpful. For this project though we decided to take a somewhat lighter approach and just sketched two stereotypical users, that mainly differ on the assumed safety-orientation and IT problem solving skills:
Primary user: Paula
- regular user of office, mail, internet
- set, female, rather cumbersome
- follows regulations
- more safety-oriented
- good IT problem solving skills
Secondary user: Jens
- regular user of office, mail, internet
- set, male, rather cumbersome
- follows regulations
- less safety-oriented
- little IT problem solving skills
Note that the target audience are people working in federal authorities. The picture we are drawing here is exaggerated. This is not due to us not understanding that reality is far more diverse, but for our purposes it helps to focus on the more ‘complicated’ users. So please do not feel offended if you should work in federal administration. Most people working there will be different.
We assume Paula to be the more important user for TrustBridge, so we make her the primary user in terms of Personas, while Jens is the secondary user.
Step 3: Scenarios
Scenarios help to derive and structure the actual tasks we define in the next step. We found two possible scenarios:
- User, managing certificates for themselves – Paula and Jens
- Administrator, managing certificates for others – Paula only
Step 4: Tasks
Tasks are what users actually want to achieve with the software. It is helpful to order them by assumed priority. Additionally it should be stated which users actually are confronted with the tasks and how often they are.
We created the list of tasks based on the given requirements from the BSI and a brainstorming session, where we tried to mimic the users in their scenarios. This is quite a successful methodology and makes excellent use of the findings in the steps before.
Table 1: Tasks in TrustBridge.
| Prio. | Description of Task | Frequency | Paula | Jens |
|---|---|---|---|---|
| 1 | Confirm / allow updates of certificates (Check automatically on start up and manually) | Occasionally | X | X |
| 2 | Installation: safeguard communication of users serviced by me; execute regulatory directives for the protection of the communication on my computer | Only once | X | X |
| 2 | Confirm / allow update of TrustBridge (Check automatically on start up and manually) | Rare | X | X |
| 3 | Installation of first Mozilla Client (e.g. Thunderbird) | Rare | X | X |
| 3 | Investigate contents of a store | Occasionally | X | |
| 4 | Select certificates | Rare | X | |
| 4 | Check certificates that are available in TrustBridge | Rare | X | |
| 5 | Deinstall TrustBridge | Only once | X | (X) |
| 6 | Get information & help about TrustBridge | Rare | X | X |
Step 5: Sketching
The advantage of such an structured approach in requirement analysis becomes visible when it comes to sketching the UIs. Creating UIs usually is an iterative process and the results so far lead us through these first iterations. The recipe is pretty simple:
- Take the most important task for the most important user (Paula) and mock the perfect UI.
- Then take the next user (Jens) and see how the UI needs to be changed for him to be able to do the first task, but at the same time to keep it great for Paula.
- Now alter the UI to allow Paula to do the second most important task, while keeping the experience great for the previous tasks and users.
- Go on like this until the last task for the every user is addressed.
A recommended and simple way to do this is on a whiteboard. You can easily erase, change or add things – and at this stage it is not important to think about screen estate or such – it is about getting the ideas to work.
Picture 2: Whiteboard with early interaction flows of TrustBridge.
Step 6: Wireframing
The UI sketches need to be transformed into something that designers and programmers can use for picking up the work. We use wireframes for that. Unfortunately the only real Free Software wireframing tool Pencil is not mature enough to do this in a proper and efficient way, so we had to use Balsamiq Mockups. As this project is done in German all mocks are made in German language as well -still we hope you get the picture. You are invited to download the .bmml mockup files and play with them.
Picture 3: Updates of Certificates.
Picture 4: List of Cerificates in TrustBridge.
Picture 5: Revoked certificates.
Step 7: Realisation
Now that we have the idea of how TrustBridge should work, making it a piece of software is the next step. Seeing and feeling the interactions, running into technical limitations or even gaining new insights from user feedback on these screens will always make it necessary to slightly adjust the target again. So see what we ended up with (the following screens are again provisional results and are likely to be change until the end of the project).
Picture 6: New Certificates found.
Picture 7: Viewing Certificate Details for Update.
Picture 8: List of Trusted Certificates.
Conclusion
As TrustBridge is a software with a limited purpose, we were able to do steps 1 to 5 in a one day workshop. For software with a broader scope you would need much more time on that. Creating the wireframes in Step 6 was the wrap up of the workshop and allowed the programmers to start working. Of course a lot of communication happened during the realization, as things here and there turned out to be different than we thought.
Overall this project is a perfect example of how user centered design works – even on a small budget and even without direct access to actual users.
What do you think about the process and the output? Do you have any ideas how to improve what we did? Did you make similar experiences in your projects? Please share your thoughts with us!