A design process in a distributed open team
Having just been through the process of trying to involve people in open source design and development, Maris Fogels (another Launchpad engineer) and I took some time to document/reflect on the process. The strongest point that came out of the Q&A for me is the importance of voice conversations for iterating a design like this.
In this Q&A Michael shares his experience helping design the ‘Build Branch to Archive’ user interface:
Ubuntu is beginning to manage its source packages as Bazaar branches, as part of the DistributedDevelopment project.
One incredibly important activity for source packages is building them into binary packages that can be downloaded and installed. This spec explains how Launchpad can make this a wonderful experience.
Mars: Have you done any work designing user interfaces before this?
Michael: A little – we went through a similar process for the PPA redesign as
part of Launchpad 3.0. Prior to that, no, only your typical “Oh this
needs a UI – let’s just start creating the UI that *we* think the
target users will want.”
We had tried (in the Launchpad Soyuz team) doing something similar to
this design process previously (particularly, defining stories for an
interaction before coding, and getting feedback from the people
representing the target users), but no matter how hard we tried, we
weren’t able to get the time with them or any feedback, and so we
ended up implementing the design and landing it without their
feedback, which was a mistake – and a lesson learned which influenced
the process I used here.
Mars: What tools and resources did you use as you went through the project?
Michael: Balsamiq, wikis, email discussions and phone calls. Balsamiq was great
as a way to create UI’s quickly, modify them easily as we learned
more, share them for others to modify (I just pushed a bzr branch that
I kept up to date).
Mars: Was there a particular process that you followed?
Michael: Basically I tried to:
- Identify and describe the use-cases,
- Create mockups for each use-case,
- Get feedback from as many people as possible,
and then constantly update or add new use-cases and mockups as more
info came in. Looking back, it seems we went through three definite
Mars: How long did it take to design the page?
Michael: We just designed the main interactions to build a branch into a PPA,
which is 2 pages/overlays (they’ll be overlays if js is enabled). I
think the process (3 iterations above of gathering feedback,
phone-calls etc.) spanned 3 weeks, on and off.
Mars: Do you think the problem was well-understood before you started working on the user interface?
Michael: I think different people understood their own domains of the
build-from-branch interaction, and everyone had ideas about how the
other parts should work, but no, I don’t think any of us understood
the use-cases properly – particularly the issues around re-using
recipes in the UI – until all the ideas and feeback was collected and
Mars: Did the design of the interface change much as work progressed?
Michael: Yes, quite a bit. Initially I had initially (mis)understood that we
needed to work with the current implementation of bzr-builder, but
after the first iteration, James Westby pointed out that bzr-builder
can be updated to support the requirements of the UI. This freed us to
consider sharing recipes in the UI in a way that would not have been
Collecting and expanding the use-cases naturally required updates to
the design. Also feedback and questions from various people helped to
keep refocusing on what people want to be able to do (for example,
“This recipe supports building to Ubuntu Lucid, Ubuntu 9.10 and Ubuntu
9.04”, while still allowing the person using the recipe to select just
the distroseries they want).
Mars: How did you get feedback on your designs? Was there a good response?
Michael: (Just an aside, there’s no ‘y’ there – they are really our designs, I
was just filtering and focusing the collected thoughts and ideas into
So as above, email to the dev list, then irc chats, but the biggest
throughput of communication and feedback came via actual calls. It’s
just so much easier to clear misunderstandings on the spot if you walk
through the process together. I had multiple calls with 6 different
people, all which were invaluable.
Mars: Looking back, what was the most difficult part of the process?
Michael: (1) Getting real user input and feedback and (2) getting feedback from
With (1) the best I could do with the time I had was to communicate
with representatives of target users, which I think worked quite well.
And (2) was difficult mostly due to the nature of the problem for
build-from-branch. IMO it requires someone to sit physically in the
office and walk through the process with a designer, something I
couldn’t do, and hasn’t been done yet as far as I know.
Mars: What did you most enjoy about the work?
Michael: Bringing lots of ideas together from lots of people, clarifying the
different needs to different people to build a common understanding of
the issues involved.
But, to be honest, I am also enjoying getting back to soyuz coding. I
enjoy doing this kind of thing for a week or two, but after that I’m
always keen to get back to doing some coding.
I think I (and James?) also enjoyed the fact that we could work on
defining the interaction *before* anything had been coded. Too often
we get in there and just start coding something without thinking
through the use-cases properly (or even defining them), and it ends up
causing a lot of pain. Like everything, it’s a learning process.
Mars: Any final words for developers looking to try this themselves?
Michael: Sure, if you’d like a change of rhythm and enjoy facilitating
conversations and ideas, give it a go – it’s a great chance to
interact with other people in different areas and build your
understanding of what people actually want to do with your product.