Problem / Goal
In contribution to Bitbucket Server’s (BbS) goal of evolving their development experience, administration settings were in need of an update. The admin settings in BbS had been neglected for some time and little was captured about nor synthesised from them. So, while we revisited settings for UI changes, we also wanted to:
• Collect more about how some features were experienced by admins and validate their goals.
• Reconsider some of these experiences to better align with admin goals.
• Future-proof the designs by considering the standard approaches cross product. 
The initial goal was to tackle repository, project and global settings. All settings were refreshed with new guidelines in mind but only repository UX reconsiderations were undertaken. 
This project was not on the roadmap, so my job was to convince developers to work on updates in their 20% innovation weeks.
Alignment with company OKRs
To kickoff this project, I aligned goals with team OKRs and discussed and reviewed scope with my manager.
Research
Throughout the project, I collaborated with and interviewed people across multiple teams and disciplines. The people I spoke to to gain a better understanding of the Bitbucket product and admin settings as well as server and company-wide design guidelines included:
• BbS designers
• My manager
• Developers in BbS
• Server product designers
• Design Systems team
People I interviewed were repository admins and production instance admin on the Jira cloud and Bitbucket server teams.
I spoke to the team product analyst to gain a better understanding of current analytics as well as how we could deepen insights with additional event combinations. Due to the structure of BbS licensing, analytics are difficult to gather and my project especially required more resources than I originally expected. Thus, I began to determine some next steps for when this project increases in priority. I identified the current events tracked in repository admin settings and considered what combination of events could be useful for future insight gathering.
Additionally, I began to scaffold an amalgam of internal insights and issues raised in order to build future hypotheses around gaps in workflows, or challenges in task completion (whether due to current features not satisfying their current ‘job to be done’ or simply not existing). These insights were aimed to inform the next design iteration cycle.
Ideation
After understanding where the project stood within the company’s priorities and conducting initial research, I split all views and wrote unknowns and feedback for each. I ensured I spoke to developers with in-depth knowledge of the settings to really understand the reason for particular features and how they linked with other admin settings (project and global). I then created ‘jobs to be done’ (JTBD) for each view and compared them with the UX of the views. This helped me build a justification for making design changes.
Research Cross Product
• Bitbucket Cloud. However, the settings still followed old UI conventions and also hadn’t been worked on for a similar timeframe to server.
• Server products. These settings also followed old UI conventions and also hadn’t been worked on for a similar timeframe to server. There were some new UI patterns which were applicable to some features in admin settings. These were taken onboard as references for the relevant features in admin settings.
• Jira Settings. The newest form of settings in Atlassian. Its general UX/UI served as a good reference for application of the new ADG in the context of settings.
After collating this information, I began working on some obvious aspects of repository settings that could be improved. These particularly included reducing expanding lists through search implementation, dropdown state changes, and revamping the UX of permissions. I identified that inherited default permissions was important to users.
Who I worked with
This project was mainly independent; however, I worked with developers to better understand the product and features I was researching. My manager helped me prioritise the project deliverables when new challenges arose and timelines changed. Designers on my team, in server and design systems teams gave me insight into their products, similar projects and workflow during one-on-ones and in design sparring (Atlassian's version of critique sessions).
Deliverables
I made ‘as-is’ mockups of repository, project and global settings and delved into repository settings research. My initial design iterations involved using and discerning from updated design guidelines to apply to each views.
During this, I sparred several iterations of initial UX modifications of some views, created and tested prototypes of them and synthesised the insights provided by team admins during testing.
One of the areas which I identified for UX improvement was permissions. Design decisions made around this view were informed by challenges in the current state identified through testing and developer discussions of primarily table readability, search, and alignment. 

Current state of repository permissions

Design iteration of repository permissions

This project was mostly undertaken in an exploratory phase aimed at understanding the problem and opportunity space. Changes weren’t shipped as Server’s approach to shipping features is quality over quantity. The nature of server product updates by enterprises being infrequent and voluntary makes our team’s releases focused around longer term research and validation. Hence, more research and validation cycles would need to be conducted before anything was shipped.
Why I did this project
During these 3 months, my personal aim was to be better able to use Atlassian’s design system efficiently and know what design methods to use when. Additionally, I wanted to more familiar about planning and conducting qualitative field research and interviewing, usability testing, participatory requirements and testing sessions, research synthesis and data analysis to generate actionable insights. For these reasons, my manager and I chose this project to promote my growth in these areas.
What’s next? ◕ᴗ◕✿
This repository research would need to be ongoing in order to measure and determine the best outcome for these views and then translate views with the same interactions goals to global and project levels. 
More time on this project would allow me to undertake more iterations on the design changes I made. I would conduct more internal user interviews with people from a wider variety of teams to gain a better understanding of their workflow surrounding admin settings in Bitbucket Server. I would test baseline usability using task success and time measures for the current views and then compare it with the same measures when testing new design iterations. Determining what analytics combinations to track, influencing the team to add additional events to the roadmap if needed, and documenting more insights based on analytics retrieved would be other next steps that I would pursue with more time.
Tangential questions uncovered
• Who is the source of truth when it comes to design guidelines?
• How can I help standardise this process of cross product research when reconsidering past design decisions?
• How can I help Atlassian have a better design onboarding process?
• How can I help Bitbucket Server gain more analytics?

More design juice

Back to Top