__Continuous integration and productivity, an approach for designers?__

__TLDR: Building good software is hard, we all have good ideas and borrowing approaches to problem solving even when its from different disciplines is cash money. __

The purpose of this blog was to both process and reflect on the technical things I learn in the hopes that some of my thoughts resonate with someone who might be in a similar career point when I write them. Some of these things might not seem positive, but are in no ways personal or directed towards the amazing team of people I have the privilege of working with. After all, to be able to get paid to design and build things with people that care about doing the same is a privilege.

After two years of programming and over six years of designing I have come to a point of realization. What makes me the most productive as an engineer seems to live in opposition with what I thought made me most productive as a designer.

One of the things I love about development is the idea of continuous integration and deployment. This usually has to do with a dev-ops testing pipeline that allows for developers to work off of a main branch merging code multiple times a day. Continuous integration also entails continuously releasing parts of a feature as it is built. This paradigm prevents you from striving for all or nothing thinking and instead encourages steady progress by accepting the idea that progression is better than perfection. There are measurable benefits to this approach, one major one being that you are significantly less likely to drastically fuck things up because you can test smaller isolated components of a feature as you bring them into a production environment as opposed to building up huge feature branches and deploying them to production all at once. You can also continuously gain insights from your users with how they interact with smaller pieces of a feature or product and tweak them as you refine ideas. Refinement is based off of feedback.

> Continuous Delivery is an exceptional resource on learning more about continuous integration. Dave Farley and his youtube channel have some quality stuff on it: https://www.youtube.com/watch?v=v4Ijkq6Myfc&ab_channel=ContinuousDelivery .

As a designer my work product up until this point has had a lot to do with the visual delight and thoughtfulness found in the mockups I deliver. Namely, how good do finished designs look? Are they exhaustive in how they approach the many facets of a problem? Can they account for edge cases, will stakeholders be satisfied? I've placed arguably too much value on the look and volume of deliverables and not enough attention to the ease of execution. I'm beginning to think the right way to design adopts an approach that looks like this.

Design and development an idea for more productive design

1. Identify a problem.
2. Break UX into steps • whats the fewest amount of changes I can make to solve this problem?
3. Once in steps, start mapping out rough UI of what you plan on changing.
4. Assuming I kept things as low level for as long as possible, come up with a couple high fidelity mockups of small changes to test.
5. Get some diverse feedback. Monitor scope creep but make sure you get another engineer, qa, pm, and designer to take a look at. Include your team.
6. Write your code, Write your tests, maybe the inverse is better - i dont pretend to know🤷‍♂️
7. Write your code, make sure tests pass, get QA and other dev input one last time before merging and deploying to prod.
8. Monitor analytics and feedback, leverage something that can track users passively while you work on design for other small pieces until there is a preponderance of feedback to iterate on. If it sucks fix it

The key points are, don't "finish" your designs before you start development. Iterate designs alongside the development process. Develop with an attitude of being overly transparent, be proactive and show your work as it is getting built instead of shelving it away in secret until it is perfect. Granted there isn't a one size fits all approach, and certain things are too big to work in this framework easily. I can say though that most of the tasks I've run into over the past year have reinforced this workflow.

I think designers can learn something from the CI (continuous integration) approach. Whether it's working smaller and going to production sooner to get feedback from users and build off of that, or if the solution is to dedicate most of the time to UX research so it takes fewer stabs or maybe it's just to work closer together with engineers and work less asynchronously. Getting feedback early on for what's being solved and not getting married to your own ideas too soon is difficult. Let everyone wear different hats and you can get something really great.