What is the best way for UX Designers to work within a large set of teams? That is the question. The answer is not easy to come by for most and involves a lot of blood, sweat, and tears to unpack the answers. The 2-bit answer is to be as fluid as possible. If you can imagine your team, or your workflow, like water it will fill the gaps and be amenable to any form of a structure created around it.
In my 20 years of process and progress, I’ve found that the agile methodology works best for developers, but isn’t always the best for user experience teams. We UXers, designing a whole and complete experience, have to see the project as a whole and know the kluge ways that people have been using the product in order to do the thing they really wish the product natively had. Or, unpack the frustrations with the thing that’s the most used on your design actually has the least visual impact, or is too hard to find. We can’t have that pie in the sky view if we have to keep our feet on the ground with constant iteration, which in and of itself is not a bad thing, but it’s not the best thing for discovering all the great things your product could and should be.
The 20 Steps, Well, kind of:
Some of these will require kicking back to areas of the process where more iteration can happen, or more insight can be captured, but this is a good base for large team interactions.
- Discovery Session with your Customers to Survey the Need Fully
- Unpack the Meaning of the Data Received, Hypothesize
- Create a Strategy for that Data, Including Choosing a Platform
- Know and Understand Basic Limitations/Advantages of Your Chosen Platform
- Identify the Information Architecture Based on the Strategy
- Create a User Flow for Interactions
- Rapid Prototype or Wireframe Initial Design Options
- Iterate and Collaborate with your Stakeholders, Developers, and Team Members
- Sign off and Agree to a Single Design Approach
- Create Accurate Design Comps
- Annotate Comps and Detail Interactions
- Handoff Annotations to Development in a Working Session
- Design Review with Development and Design
- Adjust Designs or Development
- Second Design Review
- Finalize Changes and Get Stakeholder and Business Approval
- Determine if There’s a Need to A/B Test Any Components Within the Design
- Launch it
- Measure the A/B Testing
- Test the Design as a Whole and go back to Step 1
Now that you see this, it seems as if we threw Agile out the window and went full bore on a Waterfall approach, this couldn’t be further from the truth. Actually, you are iterating constantly the entire time as you try to be adaptive to things as you become aware of them. In great processes, you find a way to be iterative but there has to be some structure to moving forward. If that looks like Waterfall then so be it. You can always enter a continuous improvement ticket in your JIRA backlog and improve the experience of the product you’re building. There are several people in your team and several teams on the project that contribute, that’s a lot of people and a lot of ideas.
The information you receive will come in waves and won’t be convenient in the times it does. I’ve gotten requirement changes in Demo meetings before where we’re showing the stakeholders our progress. It’s going to happen. All these moving parts might change your approach to the design completely.
You should also be internally testing amongst the company to see if it makes sense to exterior teams, not on the project, so you can gauge the success of what you’re building before externally testing. When I was at SOE we had what was deemed “Beta Olympics” where we would play the game we were creating with a goal of capturing internal feedback to test against and iterate to make our game better for next week’s Beta session. There were always some pronounced goals, but the primary goal in game-making was always, “Was it fun?”. Determine clear and concise goals for your testing so people can seek out the things that make it better. These goals should be tied to the customers, or users, always.