Adapting Lean UX methods to free/open-source software: Report from the GridSync design workshop
Activity: “Lean”-style workshop to develop a more usable new interface for an open-source distributed file-sharing system.
Takeaways: Refine background materials thoroughly for short events. Talk about conflicting assumptions to make progress.
Working with open-source secure tools developers, I have had few opportunities to bring design and user needs to early stages of development. Many tools are already well-established. GridSync, a GUI for the Tahoe-LAFS file sharing system, presented a rare chance to bring user needs to the development process at an early stage.
With GridSync, I was eager to try out the collaborative design methods used in lean development. Collaborative design brings designers and user advocates into the development process early, and has them work with developers to try out new features, identify potential mistakes in the team’s assumptions, and clarify and test ideas about who the tool’s users will be and what they want.
What did we do?
The 2016 Internet Freedom Festival presented an opportunity to bring together a dream team to work on GridSync, so I scheduled a design workshop. In attendance were two Tahoe-LAFS/GridSync developers; ethnographers from Second Muse, a technologist from Zimbabwe and a journalist from Kenya; and a seasoned designer with both industry experience and experience working on tools for at-risk users. (And me! I’m a user researcher.)
Development of free software is shaped differently from commercial development. Key differences include:
- Developers have limited time available: they’re often volunteers
- Teams are highly distributed
- Teams are often very small
- “UX designer,” “community manager,” or “market researcher” roles are almost nonexistent
- Infrastructure for gathering metrics is generally not there (and for encryption tools in particular, there’s resistance to building it; I’ll say more about this later)
To get the benefits of lean development within these constraints, I had to make a some changes to the usual schedule for a lean UX sprint. Generally, these were:
Shorter event time. Normally, a lean design sprint (as described in Lean UX) takes a few days, with time for group activities, design prototyping, developers going off to build minimum viable products (MVPs), and everyone converging to test the MVP and begin the next iteration. At the Festival, however, space and time for events is limited. We planned to make use of a three-hour time slot, but ended up spilling over into another slot the next day. All told, we took about five hours.
More front-loading of activities to get everyone on the same page. Unlike commercial development teams, which tend to have worked together previously, none of the user advocates or designers had met the developers before. Almost everyone in the room was meeting each other for the first time! To keep them from talking past each other, I scheduled time for presentations, to develop a shared context and understanding of the work.
First, Second Muse presented user personas they had developed from their work with pro-democracy journalists in North Africa and LGBT organizers in Uganda. The participants from Kenya and Zimbabwe also spoke about the challenges they face, which include limited bandwidth and spotty connections.
The developers then talked about the alpha build of GridSync, which makes the Tahoe-LAFS distributed file-sharing system more accessible to less-technical users. They explained what it could and could not do.
Next, we ran through a shortened version of the assumptions worksheet in Lean UX. I took out stuff about profit (which were irrelevant, given the NGO funding of this project) and asked about the second wave of adopters, because I want developers in our space to think more about how later adopters learn about tools by watching early adopters’ successful use (a pattern from Diffusion of Innovations, which more people in our field should read!)
Here were the prompts:
- I believe GridSync users have a need to…
- These needs can be solved by…
- The #1 benefit users will get out of GridSync is …
- Additional benefits will include…
- GridSync’s initial users will be …
- We will reach them through …
- The people we expect will observe and follow our initial users in their communities will be…
- GridSync’s primary competition will be …
- We will ensure users use GridSync instead by …
- GridSync’s biggest risk of failure is …
- GridSync can solve this through …
- What other things are we assuming that, if proved false, will cause this project to fail? …
- We will know GridSync has succeeded when we see …
To gauge the seriousness of failure risks, we graphed them on a chart with axes for high-to-low risk and how known or unknown the risks were. Here’s the result:
Putting off later steps. We didn’t get as far as building a MVP or doing testing; another hazard of holding the event at the Festival was that we all had other things we needed to do! But Chris, the GridSync developer, did file a number of tickets on GitHub related to issues from the session:
And we did sketch prototypes for interfaces:
What did we learn?
Refine background materials. We went over time on the first day because presentations ran long — not the worst thing in the world, because everyone needed to understand each other better! But we could have revised presentations before the event to make them shorter, and possibly had people read background material before we met, to make better use of our limited time.
Talk about conflicting assumptions to make progress. The exercise that brought out the assumptions of developers and user advocates was highly productive. It probably went differently than it would on a team where UX and developer teams worked together regularly — and for that reason, I think, it was really important.
The exercise worried me at first. Even though the user advocates had just explained in detail the concrete things human rights workers and activists in Africa need, the developers took a while to alter their assumptions about who they were developing for. They talked in non-specific terms about users who were “security aware” and “tech-oriented.” And when we were done with the exercise, one of the developers insisted that a key user need — a mobile-friendly interface — was impossible, because real security could never be achieved on mobile devices and nobody on the team was a mobile developer.
For a moment, it looked like we had reached an impasse, with the developers ready to ignore users who had an urgent need for something like GridSync. To my surprise, when we convened the next day, the developers were willing to think through solutions which might involve a one-way MMS-to-mobile solution, or a lightweight web interface.
The takeaway? It may lead to tense disagreements, but bringing a range of stakeholders’ conflicting views to light is useful to move towards meeting user needs. Without doing so, the developers might have continued working on a tool that never gets adopted because it doesn’t meet needs. User advocates might have advised potential users to use a different tool.
Do it in parts. With the tiny volunteer teams involved in free software development, rapid iteration is a challenge. It may be a while before the developer has time to implement a new feature or change the interface. Teams should plan additional sprints later in development. Keeping good documentation of design events should help the team keep track of priorities for meeting user needs even when a lot of time passes between sessions. It was ideal that Chris went straight to GitHub and not only filed a bunch of tickets that responded to the session, but tagged them for usability as well!
What needs to happen next?
Release in time for big events. If open-source secure tools developers could release new builds right before conferences like the IFF, the next round of collaborative design could be done at the event. Work at the events could also support other parts of lean, collaborative design:
Find ways to measure. Lean design requires testing ideas and changes, to see if they have the desired effect. Working with open-source tools for privacy and security, this can be a difficult proposition. Developers are hesitant to gather data on at-risk users. Even if they do have data from the Play Store or download pages, they do not generally have processes in place to test specific changes to the interface.
Psiphon does great work using what data they have to support their users. They partner with Viet Tan and ASL19 to gather information from the field on how their VPN is perceived and is being used. Other teams might follow their lead.
Meeting users from the far-flung internet freedom community for product testing is also a challenge. Again, events like IFF or RightsCon gather stakeholders who can be involved in these activities. These opportunities to do collaborative design should not be missed!
Make time for developers to work on an MVP. Similarly, to get quick changes or new features implemented in response to design sessions, time for coding must be planned at or just after design sprints. It could be awesomely productive to run one collaborative design sprint at the Festival, have developers spend a subsequent week in March building a prototype, and then test it at the end of March at RightsCon!
