There are many experts with varying definitions of UX. I am partial to the definition from Joe Natoli of GiveGoodUX.com. But, for this article, I want to get a bit more pragmatic.
With that in mind, I really like this definition from Usability.gov, an initiative of the Department of Health and Human Services. They are a “leading resource for user experience (UX) best practices and guidelines, serving practitioners and students in the government and private sectors.”
Here is their UX definition:
“User experience (UX) focuses on having a deep understanding of users, what they need, what they value, their abilities, and also their limitations. It also takes into account the business goals and objectives of the group managing the project. UX best practices promote improving the quality of the user’s interaction with and perceptions of your product and any related services.” Source: Usability.gov
Agile is a method some businesses either use or say they use. MOre often than not, these organizations are using a combo of agile and waterfall methodologies. Let’s look at each…
The more common development method is waterfall. Waterfall is a linear development methodology with iterations instead of sprints (I’ll explain sprints in a bit). The entire project has a beginning, middle, and end. Development moves forward following a preset path from start to finish.
Changes in scope in waterfall projects will cause the project to stop, and for deliverables to be amended or changed altogether. This can mean missed deadlines and additional costs.
The main disadvantage to Waterfall is that the project takes what it takes to complete. So, if it takes a year, that’s a year without any return on your investment. The advantage of Waterfall is that you know exactly what you’re building and what it will cost.
Agile is more, well, agile. An agile project runs in sprints. Each sprint has a defined set of goals and a preset timeline. For example, sprint one might be wire-framing, sprint two could be prototyping, and so forth. And each sprint is a shorter length of time, say a week or two.
Also known as rapid development, agile relies heavily on stakeholder availability. Sprints will often involve daily reviews and will certainly require a review at the end of the allotted sprint time.
So, let’s say you’re running two week sprints. That means you’ll need your project team and stakeholders to be available when each sprint ends, every two weeks, at a minimum. And a project could be anywhere from a couple of months to ongoing.
The next sprint does not commence until the previous sprint has been closed. It’s more likely that deliverables from sprint A will end up in sprint B, but only after team/stakeholder review and approval.
With these sprints, the scope is not fixed for the entire project. The scope can be adjusted from sprint to sprint depending on user feedback (if it’s live or in testing) and any user analytics.
But, Agile isn’t for everyone. In fact, very few organizations have the budget or the type of project where Agile makes sense. More on this in a bit.
Now, take what we know about UX and agile and apply that to your website. Your website must meet the needs of your target audience. These needs are likely to be ongoing and often will change based on a number of factors.
In other words, the user experience of your website needs to change and improve based on the ever-changing needs of the user. For this to be a reality, you must be able to change your website easily and often.
Remember UX is “a deep understanding of users, what they need, what they value, their abilities, and also their limitations.”
Does this mean you need to redevelop your website constantly? Of course not. But, you will need to make some major changes from time to time. This all depends on the analytics you’re getting from your website:
This is where a lot of companies fall short. They are either not tracking the success of their website or they are only getting a portion of the data available. Marketing with incomplete data will result in less than ideal results.
Here is a good beginner’s guide to Google Analytics from Chiedo Marketing.
Before, during, and after a redesign of your website, you need to clearly define what success looks like. And this should be easy to measure.
More traffic can certainly be a metric to track and improve upon. Traffic is important. More traffic means more opportunities for conversion.
But, what kind of traffic? And how much of it do you need to achieve your goals? A successful website isn’t always one with a lot of traffic. That might sound crazy but think about it this way…
What if the primary foot traffic walking past a butcher shop was made up of vegans? On the surface, it might seem like a prime location. Busy street, lots of foot traffic. But will they come in and buy anything? Nope.
You need to define success and work backwards. If success is a product purchase, work backwards from that.
You want more traffic, sure. But, you want the right kind of traffic and you need to “connect” with them. People engage with people. They buy from companies they know and trust.
Again, let’s go back to the HHS UX definition. Specifically, I want to look at your users and “what they need, what they value, their abilities, and also their limitations.”
If you can identify and target this, you’re on the right path. There are nice to haves and must haves. You need to figure out how to become a “must have” for your target audience.
If you’re thinking “well, they don’t really have to have it, they might just want it,” stop it! You need to find out what it is about your product/service/whatever that these people need.
I’m not talking about shady sales tricks or some sort of Cialdini psychological jujitsu mind trick. I’m talking about the essence of the connection they might have to your organization.
For example, let’s say you’re a non-profit organization. One of your target audiences is potential members. Why should they become a member? Just because? Nope, that ain’t gonna cut it. What’s the bottom line? Cut to the chase.
What’s the value of membership as perceived by the target user on your website? This could be advocacy, support, education, etc. It doesn’t matter as much to them that you have 1,500 members. Or that you’re the largest non-profit focused on whatever. That doesn’t hit them in the need zone.
You have to know their pain and understand their unique problems. Then, on the membership page, speak to that.
This applies to any organization selling anything. You could be selling IT services, biotech regulatory consultancy services, handmade ice cream, regulatory requirements for updated tax policies… it doesn’t matter. Your targeted user has a need and you have the solution. You must speak to that need in their language.
So, now I’ve gone on and on about user experience, but what about agile? Is agile ideal for you? Well, it’s going to be easier to provide a consistently optimal user experience if you’re following an agile style method.
Instead of spending six to twelve months designing and developing a website, only to launch it and realize you made some bad decisions, you’re rolling out updates incrementally. You now have the flexibility to make changes quickly to address any issues with your website.
You can also be more measured with your marketing initiatives. You can roll out a baseline website to start focusing on a core set of features or services. Then, as users interact with your website, you can make adjustments to improve their onsite experience. You roll out features and updates incrementally, at the end of each sprint.
Just remember, agile is not for everyone. The process requires money and a lot of management. Each sprint needs to be written out, followed, then assessed at its completion.
And when one sprint ends, you must determine what will be in the next sprint. Is it a combination of tasks not completed, new tasks based on user data, and tasks you had already planned for that sprint? That’s a lot of paperwork and management.
Plus, are you comfortable with an open-ended project plan with an open-ended budget? Sometimes, based on what you’re trying to build, this might be unavoidable. Just know that while agile might be the best fit for what you want to accomplish, it might not be the best fit for your budget or the staff /resources you have available.
So, am I saying that no one with a limited budget should look at agile? No, not at all. But, money is a factor and needs to be considered. If you can’t afford an open-ended project, maybe you can do things in phases in a bit of an agile/waterfall hybrid…
You have a fixed set of deliverables but for a much smaller portion of the project – just enough to go live with something. Then, after some real data comes in you look at starting phase two.
Which development methodology is going to deliver success? Is it agile? Waterfall? Or some combo? (of course Agile purists will hate the idea of a combo, but they don’t have to pay your bills!)