Meta
Meta copied to clipboard
BitcoinDesign
Bitcoin Design Sprints
This is a tracker issue for Bitcoin Design Sprints, formerly known as the Wallet Improvement Project.
The mission is to run design sprints for community projects, currently with a focus on mobile Lightning wallets. A group gets together to research, brainstorm, concept, and propose solutions to improve the project at hand. More about design sprints.
Creating a tracker comment here for the Blixt project, which is the focus of the first design sprint:
Day-to-day communication happens in #wallet-improvement on Slack.
Calls:
- Introduction
- Sprint #0 to define the scope and focus
- Sprint #1
- Sprint #2
- Sprint #3 to review 3 directions
Files:
- Initial project doc
- Figjam sprint board
- Figma base storyboard by Johns
- Figma by Stephen (Feb 24)
- Figma by Raj (Feb 27)
- Figma by Mili (Mar 3)
We can keep updating this with links as needed. Just thought it'd be good to have these in one place.
Brief update on this by Mili. Herself, Mo, and Hampus reviewed the latest designs and decided on various tweaks to the onboarding content. Once those are resolved, they will move to high-fidelity designs.
The project has continued in the #wallet-improvement channel via several calls. Goal is at the moment to finalize the onboarding flow, create and test a clickable prototype, and wrap things up nicely with a case study.
- Call recording from June 29
- Call recording from May 25
- Call recording and issue from March 18
@GBKS I see that this project is presently in the user testing phase. Can I help test the product with users? Is there a team of UX testers already? If yes, I am very interested in joining that team and documenting the key takeaways. I can also help with creating a testing script
Hi Shalom. Thanks for your interest. This is the same project you already commented on here. @mouxdesign is currently wrapping it the final summary case study, so the design and research work is complete.
Are you looking to contribute to bitcoin research projects specifically?
@GBKS Yes, i am research focused so i am looking for research projects/UX projects to contribute to. Thanks
With the Blixt case study page now live (via this PR), we have wrapped up our first sprint. It ended up taking much longer and more involved than originally planned. Part of this was also scope creep. Instead of just doing the initial brief sprint, a few people continued to go through multiple full design iterations and testing (super cool they did).
We don't have any plans for further sprints, so should we close this one? Does anyone feel strongly that we should continue this format as a series (an alternate approach would be to do sprints in the context of projects as they come up - instead of a continuous series)?
First and foremost, somebody needs to love doing this and own this. If somebody wants to step up and lead this effort, it would be cool. And they should be scoped more tightly and limited in time.
Nothing wrong with a long-form design project. These sorts of long-form projects can be really nice, but then it becomes like any other Community project collaboration, e.g. Alby, Zeus, Bitcoin Core, etc. and sort of has its own project management structure.
So if nobody is stepping up to lead this effort, let's close it.
Agree it should be very tightly scoped. I think Mo was working on something regarding a new proposal to the format.
My own format is 8 days. Last time, with the open design format it seems to have broken down when entering the prototyping phase. So I would suggest next time if we continue this for that activity to be really strict to the sprint question that were settled on during the interactive sessions with the wallet maker. Can't solve all problems, have to be happy with imperfection but once it's tested it gives us a lot more context in how to move forward.
Happy to close this one as well. I think that the lesson learnt is that there are alot of projects which pop up in the community which reach out and request some form of collaborative effort. Lessons learnt:
- It feels much more relaxed doing these collaborative efforts when the project themselves are invested in the redesign process. So often a project reaching out is an indication of their dedication/openness to redesigning (versus the community reaching out to a project and offering help)
- Time constraints: A project setting up their own slack channel/inviting us to their Discord is also a nice continuous way of working with/alongside these projects.
- Opportunities to learn: The original way of doing a sprint would be to use a design sprint format. I love using a structured approach however I have also learnt that we can learn alot from different open source projects by gaining some insight into how they would choose to do the re-design. We can learn from these projects/methodologies and ideally share them as case studies in the guide.
A good approach would be documenting these and sharing them as case studies in the guide as a time investment versus spending time approaching projects to sprint with. Allow the projects that are currently moving forward consistently to shine and learn from them and help them in any way we can.
Alright, I think it's time to close this issue now. We are still working with plenty of projects directly, just not as a series of sprints in the format outlined here but more based on need and context. If you'd like to open this issue up again for some reason, please state so and we can do that.