Solid UX + great design + efficient testing = $$$
By: Daryl Duckmanton
Tags: User Interface, UX Design, Testing, Software Development, User Experience

I write to you today as a developer. I have spent years in this industry developing systems for many different organisations. I have personally witnessed many companies devise strategies of how they will produce the best product on the market.

They document some requirements from a handful of people in the company, build those requirements into user stories, and hand over these stories for developers to build and testers to test. The requirements of the software are very “top heavy”, meaning that only very few people actually get to specify how the software actually works. Not to mention in a lot of circumstances, these people know very little about software and how they are developed.

At the end of the day, your requirements should be gathered from your audience, not by a handful of people. And those requirements should be reviewed by all parties of your company. The more opinions you have about how something should work the better. I would recommend that research should always be done before any requirements are documented and given to any team for development.

UX is key to getting a system right the first time, and to limit the number of iterations a system has to go through. This does not mean a system does not need to evolve based on how society changes and grows, but it limits the amount of “changes via sudden discovery”.

To support UX is to have the right UI to support the problem that UX is trying to solve. A good looking and easy interface is also key to a system, and needs to strongly support the requirements at hand. Forget how you are going to develop the system, if the UI is garbage, and people do not know how to perform certain actions on your application via your UI. Users will simply not use your site if the UI is too complicated to understand.

When and only when the UX and UI is established and tested against a range of your target audience (via UI testing such as wireframes and designs etc), should your requirements be documented, prioritised, and released to the development team to undergo development, starting with your MVP (most viable product).

Once handed to development, our agile cycle of development can get underway, but before a development team gets started they should analyse the requirements of the system (for the MVP and maybe a few more features onwards), to establish what kind of system we are building for our target audience.

At this time, the team needs to ask the questions that UI and UX designers may have not thought of. Such questions are more around the readiness of the data in the screens and how to handle particular interactions in the system. Can we have some delays for certain actions? How long can that delay be? Developers generally need to know if some data in an action is transactional or not, or we can queue off certain tasks for batch processing etc. These kinds of questions will drive technical design up front.

Iteration 0. What is it? To me, it’s to get stuff ready. Build a skeleton of how the system will work, allow testers time to build test cases for tasks and ask questions etc. Some agile teams don’t believe in iteration 0, but to me I feel every project needs a preparation period, otherwise you will spend too long, writing core logic for features during iteration development. Iteration 0 allows for research of technologies, to see what will work or not work for particular problems. The difficulty of an iteration 0 is how long does it last? Do we give it the length of a sprint? 2 sprints? I think the length is based on the complexity of the system, and all parties (from developers to stake holders) need to agree on the length of time this goes for.

Now we finally start, and what is the first thing we should focus on for each feature. Before each feature is developed, I think it’s clear that the developer, tester and the product owner are all on the same page on what will be delivered for a particular story and ensure that the documentation of the story is accurate before the developer and tester starts their work. We want to limit the amount of adjustments as possible.

Once that’s done it’s extremely important that the developer and tester work closely to establish what kind of test cases will be covered for the feature. Business Driven Development is key to establishing that the system is built right and is robust on first delivery. Supporting BDD, developers should be focusing on Unit Testing and Integration Testing to ensure that their code works, and can be verified on each release cycle of the software. If you support BDD properly a lot of your unit and integration tests support a “Non UI” version of the business requirements. Once built and all code tests are written, our manual testers should only need to verify that the agreed test cases have been covered and pass before reporting the feature as “Done”.

My thoughts on automation UI tests is this. It’s ideal if you can fit it into the cycle, but if you can’t, you should at least cover the most common scenarios. Such as logging into a system, or changing account information etc. This is mostly commonly known as smoke tests. I think smoke tests should at least be done for a project if possible.

Now I know you’re wondering, where do us developers get a say on what tools we get to use, or how we should develop the software. The truth of the matter is we don’t. Not until all requirements are documented and all questions are asked. .NET might be our skill, but honestly we may find that for this particular software, using AWS Lambda and Node will be the right fit for the job instead. Developers tend to get defensive on what tools should be used, because of the skill sets they possess.

This is the wrong behaviour and this is why I stress to other developers the importance of being tool agnostic. We are problem solvers, not just coders. If you watch my YouTube video above I describe the difference between how a coder behaves vs how programmers behave.

Companies need programmers. Coders can be hired if you are after experts in a particular language and you want it written quickly. But programmers must be able to think about problems regardless of languages used, and that’s what makes them valuable. In order to deliver the correct solution for your stakeholders, you must be able to put your preferences aside and work with the tools that benefit the project at hand.

No more pushing No-SQL solutions into a relational database. If your data is hierarchical and not relational, use a document database. If it’s highly relational, use a relational database. If the entities have different kinds of relationships between each other use a graph database etc. Do not be scared to learn new things. It’s just going to make you more knowledgable and valuable overall.

Overall as much as I find it hard to admit as a developer, it’s UX, UI and extensive testing that ensures the success of a software product. Us developers just build around these ideals using whatever tools make sense to ensure that we deliver the product that is in demand by our stakeholders.