What the hell is UX anyway?
What is it? Do we need it? How does it fit into Agile development? How can we as designers and developers all just get along and sing Kumbaya?
Many industries seem to be in a digital panic mode. Everyone knows that digital is where they want to go but how do you get there? How do you beat the rest and do it well and fast? You may have heard of terms such as ‘Design Lead’, ‘User Experience’ and ‘Human-Centred Design’. In this article, I’ll unpack the minefield that is product development and share my experiences as a UX designer.
So let’s set the scene: Industries are scrambling to make the next big tech breakthrough. You may be hearing phrases like “We need to get this out quickly”; “I want all these cool features that I know everyone will love.” and “Can you do it at a low cost?”. The pressure is on!
As a UX designer, I can’t complain because that’s what has made our skills so necessary and in demand; however, it can get tough to navigate. Sound familiar? So how do we as engineers, designers and product owners deal with budgets, crazy deadlines, skepticism, delivering at scale and getting business to buy-in? How do we create interfaces that make a user fall in love with our products when the clock is ticking?
By being in many product teams over the years I have found a few tricks that could help make the road a little easier. I will start off by explaining what UX design is and how this fits into the development cycle.
What do UX designers do?
UX designers want to know the type of environment a user will use their product in and how they feel while using it? Do they hate or love anything about doing this task? What would make their lives easier? This is the basis for Human-Centred Design and Design Thinking.
As designers, we use the people we are solving the problem for, to help us solve the problem. It’s a simple concept, but it does have its challenges.
How do we implement design thinking into our projects?
Issues such as time, budget and product impact come into play. Clients shy away from extensive testing and research as they can become expensive and time-consuming. They would rather build the feature and then get their feedback from users. The problem with this is that often, we never get a chance to go back and fix these issues as there are always new features to build. Why should they pay more money to rebuild something? I have encountered this more often than not. How do we deal with these inhibitors and still include User Testing or User Research into the mix? This does not have to cost a fortune, and it doesn’t require a team of UX designers.
However, that said, if you do have the time and money, then it is always best to do extensive research and testing. It will make your product! If not, then you need to be “scrappy and crafty”, like me. It’s better than nothing. I am not saying that I do it according to the rules every time, but I have found ways to do my best with what I have. Do what you can, but do something.
There are two methods that I use in a crunch: Guerrilla Testing or by finding a Sponsor User.
* Handy tip: If you test with 5 users you will discover 80% of your usability issues. Don’t believe me? Read it from the father of UX himself.
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
Guerilla testing
This can be done for products or software where users are readily found. For example, if you are creating an online shop, potential users will be easy to find. Go to a coffee shop with R400 in your pocket, put a sign on the back of your laptop (like the one below), and ask someone to join you for a few minutes. As thanks, you can reward them with their favourite coffee.
A Sponsor User:
This works in all situations and is an excellent method when your software is specific to an industry, or your users aren’t the average folk on the street, for example, software for mining engineers. It is a good idea to interview a few of these users initially to discover their pain points when completing the task, what their needs are and what their current process is. From there you can focus on one or two Sponsor Users going forward. This is a dedicated user that you will repeatedly test through the product lifecycle. Skype calls, and screen sharing works well if the user cannot come in for testing.
What I love about these techniques is that anyone can do it. With some guidelines and practice, you can get the information you need.
How do we take all of this and fit it into a Product Design sprint?
Let’s take the average two-week development Sprint. It works fine when your backlog is groomed, you have fleshed out your acceptance criteria, your designs are ready, and everyone knows what he or she is taking into the sprint. Now we can go and deliver our 20 points for the sprint. Totes!
Until the UX or UI designer walks in and wants to make changes.
This usually happens because:
1. The designer’s sprint was not planned for, given enough of a run-up or in some cases, not even thought of. Sigh! Unfortunately, this tends to happen quite often.
2. Designers are researching, designing and testing the same features that you are busy building in the same sprint. (Oh, my shattered nerves!)
3. The designs have not been followed, and we end up shouting at you in UAT. Grin. Don’t hate me, let’s talk about it!
Let’s now look at the human-centred design process and its stages. We can then move on to how (in a perfect world) this should work in an Agile environment.
Human Centred Design explained:
1. Empathy
This is where your initial research comes in. Who are your users? What are their needs and pain points? In what environment will they be using the product? How will they feel? In this stage, we find out as much as we can about the user. The more we know, the more we can place ourselves in their mindsets and design something that speaks to their wants and needs. This increases with every interview and as you delve deeper into the project.
2. Define
Now that you have heard from your users, you can define the problem that your software needs to help solve for them. You empathise with the issues that they are facing and how you can help alleviate these. This becomes your focus and barometer in your design of that feature or product.
3. Ideate
Oh, my! Here comes the fun part. Time to get stuck in and start problem-solving! We use the information we have from our research ,usability studies, best practise guidelines and process to come up with a few variations to solve our defined problem.
4. Prototype
Now that we have solved the world’s problems, it’s time to take our rough designs and rapidly prototype them. This is not coded and should take little time. What you want here is something that you won’t feel precious about, it must get your message across but not have you fretting over colours choices or button shapes. You can even draw your screen designs on paper and prototype with these.
5. Test
This is the reckoning my friends (Ps. this is why you don’t code or spend hours on your perfect design). Put the prototype in front of the people who are going to use this product and watch all your assumptions and all of your expertise and knowledge go up in flames. #kiddingnotkidding. You think that you have the perfect solution, but your users will surprise you every time. EVERY. TIME. Be prepared to die a thousand deaths.
Once you have completed these five steps, you collate the results, find the problems with your designs and start the cycle from step 3–5 over again. Yay!
Onto the Agile Development Cycle:
Agile Workflow explained:
1.Design
UX/UI Design and design of development architecture
2. Build
Feature is coded (I am a designer so I can’t really expand on this…Fresh hell starts here for my dev peeps! #loveyoulongtime :)
3. Testing
Code is reviewed and sent into a QA environment for testing. The feature is then tested in UAT and signed off by the Product Owner and the client. It is always a good idea for the designers to have a view of the interface before UAT so that any small changes can be fixed before the client sees it.
4. Release
Feature is deployed to a production environment. Once the feature is in the user’s hands, feedback is gathered to track the success of the release and then any feedback is brought back into the design process and the cycle starts again.
Nirvana explained:
Where design and development meet:
What I love about Agile is the ability for the team to find their groove and to discover what works best for them. After many tries and failures, this is the best way I have seen to merge design and development into a place where everyone is happy and trusting of each other’s skills and deliverables.
In “Nirvana”, designers have at least a two Sprint run-up to do their thing, learn about the users, define the main problems and test their assumptions and designs with said users. We have the room to feel confident in what we deliver to the development team is tested, thought about and ready to the best of our knowledge for human consumption. This approach also mitigates the mess of UX, UI and developers working on the same features at the same time. It makes me sweat thinking of the frustration this causes, never mind how this compromises the end product.
Now everyone has all the information needed to get on with his or her tasks and the freedom to complete the job to the best of his or her ability. (And to make magic!)
Admittedly we are not all working at tech companies like Google or Facebook where these processes are entrenched. We are all still finding our feet and trying our best and sometimes that means finding ways to hack the system.
The best outcomes come from developers and designers working closely, building trust and collaborating on design and development decisions.
Moral of the story: Let’s be friends :) You’ll see the results in the end product!
I have so much more to say on dev/design working relationships and how we can run quick user testing but I think I have said enough for now…
Next time…
