What does a UX process look like in your company? The most common response that we hear is: Well it depends.
And why wouldn’t it depend on a variety of objective factors such as nature of the project, client, deadline, experience and so on?
“Developing your personal workflow is almost as important as developing your personal style.”
Most designers think in terms of your typical circular model with milestones. But today I’m here to turn all this upside down and to tell you that basically, you are wrong to think that way.
The reason for that is that such model of thinking is no longer sustainable in today’s reality. The biggest and most common mistake that every designer makes is thinking that somehow UX is separate from the product and needs to accommodate it. I strongly believe that UX is the product, since not a day goes by without someone posting an article about how it’s all about user experience and customer satisfaction. That these elements are essentially best at everything, they are the best form of marketing, they are best goals and they are your first and foremost consideration.
So why is that, despite our mad obsession with user experience, we still don’t view UX as a separate entity?
Well, for starters it prevents people working in a vacuum environment, where UX researches and product managers don’t really have a clear vision and understanding of each others contribution. Everyone on a team needs to work towards a cohesive product as efficiently as possible.
It allows a cohesiveness between Software and UX designs, as both are being completed in increments.
The reason why everyone is talking about Agile UX but nobody really doing it is simple – aligning these two is not easy. Agile involves quick product sprints and really fast iterations. The UX on the other hand is completely opposite as it usually requires really long user research and even longer design hours.
“start producing consumable but not necessarily deliverable-worthy”
So the first thing on the menu to actually make the entire UX process more Agile is for the UX team to make sure that all of the project’s activities are outlined and made clear to everyone from the start. All of the UX activities need to be broken down into subtasks so that agile teams can effectively create a schedule of deliverables and deploy project goals.
The starting point of your switch towards agile needs to be figuring out what you want the users to take away from your UX. And all of your activities needs to be linked to that goal. Once you’ve defined an array of UX activities, you need to break them down into subtasks, or user stories.
One of the best ways to organize these stories is to put them into product backlog and then prioritized by the Scrum master. Victor Conesa, the Product VP of Justmind for example suggests using color-coding for easy access and greater visibility.
Why do you need breaking everything in chunks? Well, according to the Annual Report Design Best Practices by Leslie Kraemer: “Every bit of information can be linked and contained in a way that makes it easy to understand.” The report delves deeper into emerging design trends and discusses the success of implementing the Agile methodology in Shopify, one of the most popular ecommerce platform in the world.
Breaking down the activities into subtasks has less of a chance to backfire time wise, simply because there is practically no chance of task-repetition or task overload.
Any agile process aims at achieving more in less time. That is why measuring the size of a backlog and calculating velocity is of paramount importance for the success of your project. The best way to lay out any estimate is to start tracking time in a sprint. This also serves another purpose - billing clients properly and accurately. One of the best ways t track and set time log is described in Configuring Estimation and Tracking by Atlassian.
Another important aspect of timeboxing the UX process is to prevent the idea fatigue. When there are certain limits set for your activities you ensure that your goals are realized on time and no stage will be overworked. A nice way to keep the flow cohesive is to set daily scrum meetings, where your team share their contribution to the project, it also keeps the entire team informed on the stage of the project.
But as a manager you should also start timeboxing this activity as well. Don’t let the daily meeting to go more than 30 minutes. Also you can start keeping “Velocity” charts that indicate your team success sprint by sprint. These and some other metrics are described in yet another research by Atlassian. However, to put in in the military terms “No plan survives the contact with an enemy”, which means that you should always save some time for unexpected complications and any last minute changes.
Not many people realize that this is the most important part of the entire workflow. This stage pretty much makes or breaks the project.
Any project starts with getting to know what is it your customer really wants. And with that, you need to define some of the very important aspects that will essentially form your User Flow. Most common elements of this initial skeleton are desires, barriers, deadlines, and preferences. And in order to better understand those you need to start with some basic:
Pre kick-off questions. It’s what called in sales as needs discovery. You need to find out how your customer is interacting with their customers, what they would like to change, who are the main competitors and so on.
Kick-off meeting. This is the starting point for your team, where you’ll spend about 4 hours just brainstorming and going through pre kick-off questions. In addition to that you need to form a persona workshop - usually, it’s a simple word table that breaks down customers into categories and discusses what are their expectations, fears, roadblocks and purchasing decisions.
The first step is pretty much the most important parts of the entire project. I don’t care how talented you are in the field of UX design, but if you are not designing an application that serves user’s needs, then it’s useless.
“prototypes are, by their very nature, disposable”
When working in agile way on UX it is important to realize that some compromises must be met. Everything we’ve talked about before is leading up to this point. The contribution part of the velocity diagram should not exceed work completed to often. The time estimates that you put in front of your UX team should help them to keep pace with the rest of production. This is especially true of the wireframing and prototyping stages of the UX design process.
The UX designers should not spend valuable time on details that could be worked out further down the line. The prototypes are, by their very nature, disposable and need to be just good enough. You should start producing consumable but not necessarily deliverable-worthy designs that can be simply communicated to the development team at first. And while they are doing their job The UX team can actually focus on designing the best solution. This will save you a lot of time.
This idea was really well described in one of the Medium articles by Sophie Paxton, a successful UI/UX designer and blogger.
Integrating Agile methodology into the UX workflow can significantly boost the efficiency of your team, if done right. However, it is not a one-step process, any significant changes to the workflow should be implemented gradually. The more your workflow is refined to your specific organization the more clients you’ll be able to serve.
The thing to remember about agile process is that it’s goal-oriented and fits best when you are trying to increase client-turnover, so to speak. And agile is not one-size-fits-all kind of workflow, depending on project’s nature you should change approach and stay flexible.
Submit your request (be it a detailed specification or just an idea) using our form bellow.
We will contact you shortly to clarify your project requirements.
We will provide our free non-binding bid or proposal for your review.