Creating an Agile Design Process

Sometimes you have to tamper with a well-oiled machine

When I first began at @CrowdSurge it was a solid product with minimal design oversight. The developers and Product Managers wore multiple hats when necessary and built a product that worked for people. Revenue was up, stakeholders were happy and life went on without a full-time Product Designer (this revelation that a company can sustain without a design process is unsettling to a lot of designers — how do they survive without us!)

We all knew our core product would benefit from being properly designed, but no one was demanding it at the time. I just assumed that our customers were facing problems that we didn’t even know about, so we had a problem we didn’t know about. We had gotten this far based on our instincts, but in order to get to where we wanted to be we would need to expand our knowledge about how our customers were using our products by closing the feedback loop.

Knowing that I had to introduce another process on top of a well oiled machine was intimidating. I am the sole designer that’s a part of a 17 person engineering team that’s spread amongst 3 continents. Some of these engineers know the system like the back of their hand and had been working on it longer than I had been working as a designer. I knew that the only way to make this feedback loop work was to build off what we already had in place and deliver results, quickly.

The first step we took was a retrofitting of our current SCRUM system to make sure that all customer facing components were being developed based off designs, and not the other way around. Our SCRUM master had done a great job of whipping our development team into an SCRUM system, but projects were moving at such a fast pace that they sometimes skipped the design process.

Preventing this from happening meant being proactively pitching my tent in the developer camp. With the help of the product team we began flagging customer facing stories before the developers had the chance to develop them, so that they were developing based on designs and not the other way around. With a balanced design and development process gelling, projects were now being designed and then developed. All we need was that missing feedback loop.

4 Step Breakdown

Looking at how to add in the user testing component, I realized we had almost all of the components necessary to follow the process of hypothesize, build, test, learn and repeat.

1. HYPOTHESIZE

Running an agile SCRUM system gave us a clear and organized set of stories that could easily be broken down into hypothesis. We knew exactly what we wanted the outcome to be and had transparency of when it would be ready to test.

2. BUILD

Our 1 week developments meant that we would always have something new and ready to test at the end of the week. By keeping our sprints short, we never became too committed to a certain design or approach.

3. TEST

Although the testing methodology should always vary by what you are trying to test, for the most part we were looking to make quick gains and verify our basic hypothesis with remote user testing. We would write what we thought the product did, and then asked people to accomplish that task on their own without any help.

4. LEARN

In order to leave little room for interpretation with the user testing results, we make sure that our hypothesis are non objective. If the person testing our software cannot complete the task, then our test is a fail and we flag that story to be re-designed. Simple as that. This way we avoid spending large amounts of time documenting, interpreting and de-briefing the results.

So far we are several months in to this process and everything is going well. If you are thinking about integrating lean UX into your SCRUM flow or any process for that matter, you need to make sure you are doing it for the right reasons. Although I did integrate into our current SCRUM system which made it easy for developers to get on board with, I did not choose this structure just to minimize their effort needed to transition to a new workflow. I saw that it would work well within the current process while reaching our goals.

With any implementation comes a learning curve and ways to improve, but as long as you are committed to getting your product tested and asking the right questions, people will start to depend on the value you provide.