{"id":16762,"date":"2019-01-20T13:42:22","date_gmt":"2019-01-20T21:42:22","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=16762"},"modified":"2020-06-15T01:24:45","modified_gmt":"2020-06-15T08:24:45","slug":"designing-for-a-dev-environment-in-9-steps","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/designing-for-a-dev-environment-in-9-steps\/","title":{"rendered":"Designing for a Dev Environment in 9 Steps | UXPin"},"content":{"rendered":"

\"design<\/p>\n

Agile is the most common methodology for software product development today. And, it makes sense. <\/p>\n

In the waterfall days, designers and developers followed requirements that were hundreds of pages long. Products were fully designed, and then fully developed. When the product was eventually released, there was no time to go back and fix what didn\u2019t work well.<\/p>\n

Personally, I thought the waterfall days were really hard. We rarely held meetings in the same room with the developers, so it forced me to interrupt them at their desks \u2013 and that, was a daunting task. I get it; they\u2019re busy and they didn\u2019t want to be bothered by a web designer, and we really had no common ground for communication.<\/p>\n

Design was evolving so fast in this space, it was more about brand and not yet about the users\u2019 experience. Still, it was clear that I had to work with developers directly, and I had to be creative in finding ways for them to want to interact with me. <\/p>\n

Here\u2019s the kicker: In the end, it was chocolate<\/em> that was the common language for us. If I approached anyone with chocolate, that person would take the time to work with me and even teach me a little JavaScript.<\/p>\n

I was first introduced to Agile in 2009. My first stand up had 40 people in it \u2013 and stand up was never ever 15 minutes. However – the process got the right people talking together every day. Over time, we learned to make our teams smaller and our sprints shorter.<\/p>\n

Agile challenges us to create small slices of a product that is usable. Our sprints are typically two or three weeks long. During the sprints, the team can focus on problems and fix them quickly – and often, this includes design and UX issues. Missing icons, UI elements and UX that doesn\u2019t work as designed are issues that pop up in-sprint, and need immediate attention. Each sprint, we share these pieces of working code with our users to get their feedback. This allows us time to pivot and redesign as necessary, improving our products in an iterative way.<\/p>\n

Large features, however, can take the design team weeks and sometimes months to research, design, review, test, adjust the designs, retest and review with product and development before sprint planning.<\/p>\n

Where does that leave designers? <\/h3>\n

How do we think about a feature far in advance and leave enough time to complete the design process? How do we pivot and jump into a sprint and solve problems mid-sprint that might need user testing?<\/p>\n

Let\u2019s start by taking a look at the full process of designing a user experience.<\/p>\n

l. Discovery<\/p>\n