Well it was bound to happen! The Colouring-In Team have regressed to our childhoods, picked up our crayons and got creative!
Our previous work, pretty pages such as new View Issue, Issue Nav and dialogs, have all had quite small scope – though they weren’t small pieces of work. The next section we plan on attacking is codenamed “Project Ignite” and is all about project configuration.
There are 2 main targets for this release:
- New Users (primary) – Allowing them to comprehend the power of Jira quicker and in a less scary manner
- Experienced Users (secondary) – Allowing experienced users to visualise their projects and make changes a lot quicker.
The Problem
We all know about the problem we are trying to solve with the Admin Section, the problem I am talking about here is the problems we were having with the process.
The size and scope of this project is BIG to say the least and such we have been struggling to move forward with designs that got a tick of approval from Design, Development, QA and Product Management. The problem was that we would go through a daily cycle of Design creating a mockup then critique from the other parties. In a team of specialists it very hard to collaborate in realtime as usually at least one the members (usually more) are being vastly under-utilised.
We needed a process that allowed everyone to contribute on the same level and allow everyone to communicate in the same visual language. With this in mind Jay proposed Paper Prototyping.
The Process
It is basically rapid prototyping using paper, child-safe scissors, pens and cellophane. The prototypes are fully (manually) interactive – tabs swap in and out, dialogs appear and can be dismissed, buttons and links can be clicked, content can be updated. When I say “rapid prototyping” I really do mean rapid! We split into 2/3 groups and had about 5 minutes to come up with a solution to a particular problem, after which we would present them to the rest of the group and critique them. We then iterate over this process until we come up with one or more possible solutions we are happy with.
Some interesting Observations
- Paper is NOT low fidelity – Yes, it look primitive but the level of interaction you can mock out is very, very high.
- It encouraged everyone to participate – There aren’t many times when QA, Design, Development and especially Mangers can contribute on the same level
- Stealing ideas works really well! – Whilst the original designs from each group where quite different, by the end there were alot of similarities across them. This happened when one group came with a really good idea and the other groups stole it in there next iteration.
This doesn’t sound that great but on numerous occasions the group that stole the idea would modify it slightly to be even better and sometime even just use the idea and implement it totally different for a better result.
- Break problems down in smaller chucks – We initially tried to solve the problem as a whole but it just didn’t work. We had a lot more success when we tried to solve user stories than an epic.
- Front End Developers just want to code it – Out of our small sample, both front-end developers kept wanting to jump into their machines and create examples. I think paper prototyping is close enough to what they do that it was harder for them, where as PP is so far away from what everyone else does on a day to day basis that it was easy to make that jump.
- It gets a bit competitive – There definitely felt like people were trying to “win” and as such pushed their own designs further and kept critiques of other’s designs plentiful.
- Critiques are not personal – We did struggle with this for a little bit and people started defending their own designs a little too much. Once this was pointed out, things went a lot smoother.
The Outcome
All in all, I though it worked really well and we came up with some some really creative solutions. We got further in a day than we had in the previous month. JT had done some awesome work (and a lot of my ideas were stollen from his early prototypes) but the feedback loop was just too slow. This was real-time collaboration in its truest sense and I think results speak for themselves.
Here are some examples of the prototypes we came up with:
I wish we had captured a single design’s evolution over the whole session.
Recommendations
- If you are starting out a project with complex user interactions – I HIGHLY recommend paper prototyping.
- I have a feeling, the more you do it, the more beneficial it will be.
- Have someone experienced running it (Jay Rogers)
- Make sure everyone understands the problem space before starting the prototyping.