How we approach software
Compared to many design and build practices before it (like architectural design) software changes at an alarmingly fast rate. But thankfully, the underlying practices of understanding problems and designing good solutions have much deeper roots.
The end-to-end process we go through when delivering any feature or solution can be broken down into the following 5 overarching steps:
It’s important to understand that in an agile process we may iterate through these steps many times as we build new features and releases. These steps aren’t something we do once for the whole project, we pass through this process continuously.
Understanding - Research
Understanding users is key to success. Users may not always be obvious – not all applications have a user interface, sometimes they are just invisible connections between systems. But at the end of every business goal is a user – customers, staff, stakeholders. We must understand these users and their needs in order to deliver value.
We have to understand:
- Who the user really is
- What they’re trying to achieve and how
- What their current experience is
- Their limitations and expectations User research is most effective when it’s conducted as a team activity, not just by a single researcher.
Understanding the context and business case for any system is the other key to success. Organisations are complex, fast changing structures. Many times, they are poorly understood even by the people inside them, and so initial understandings and proposed solutions may only partially address the problem, or work for limited users or stakeholders. It is impossible to develop a perfect solution, but understanding the trade-offs is vital.
We have to understand:
- What the underlying business need is
- What does success look like?
- What is the ROI?
- The current business systems and process
- The human element, including limitations and training requirements
How we research
Good user research is about paving the way to understand what will work, rather than what is popular. It should challenge assumptions. It shouldn’t focus on technology or implementation details, rather on the fundamental problem and solutions. We have to talk to users to really understand them.
Key methods include:
- Reviewing existing material and data
- Talking to people organisation wide and using surveys
- Interviewing, observing and recording existing users
- Contextual research
- Prototype testing and iterating
Who we talk to
User research must be inclusive. We have to consider people with disabilities, people who are less technically able, an entire range of possible devices, mediums and abilities. Services and solutions need to be universal.
How we find and target these people is entirely dependent upon the project. There is no one size fits all solution.
Recording research findings
There are many ways to record the data from user research. But unless it is recorded in a way that is easy to understand, it does not become useful information.
The important points are:
- Research sounds natural, it is recorded in a human voice
- Research can be tied directly to ‘user stories’ and outcomes
- User groups are clearly understood and considered in the solution
- People outside the team can understand the findings clearly
Understanding - Diverge
One of the key phases of understanding is to allow the team to diverge.
As data is collected, the solution can feel further away. Assumptions are broken, there may be many contradictions.
People will start forming their own ideas and solutions, which may be wildly different. During this phase this sort of thinking should be encouraged, even though it may be counterintuitive. This is a creative process. It is common for there to be a bit of friction as different ideas and understandings form.
Understanding - Converge
In the final phase of understanding, before a team can move into the planning phase, they must start to come back together and move towards a common understanding and goal.
It is not the goal to converge upon a fully specified solution at this point, rather to converge upon a common understanding of the needs, requirements and outcomes. Potential solutions should be understood, and the business trade-offs of these understood too.
Planning - Evaluate tools and systems
Every solution is different. Sometimes it is tempting to jump into a technology or toolset we are familiar with, or which seems will give us the fastest turnaround.
Before we can make choices about the technologies, tools and components we use we have to:
- Understand the options, and the trade offs
- Understand why existing choices (such as legacy systems) were made
- Explore potential opportunities
- Think about the future, project evolution and change
The best solution to get going quickly may not be the best solution for long term maintenance. There are no silver bullets in software, it’s always about measuring trade-offs.
When evaluating technology, be it languages, tools, platforms or components the considerations should be:
- Be cloud first
- Privacy and Security must be integral
- Consider scalability
- Consider single points of failure
- Consider cost and ROI
Planning - Understand privacy and security issues
With the introduction of the GDPR user data, privacy and security are more in focus that ever before. Privacy and security shouldn’t be afterthoughts or a box checking exercise at the end of a project, they should be built right into the fabric of a solution, and often influence the solution itself.
The four key areas we focus on are:
Data should only be available to those parties whom it’s meant to be available to, and for a period that complies with relevant regulations and policies.
Information, and the system itself should only be able to be viewed and modified by the parties authorised and intended to do so.
The system should be resilient. Attacks or internal problems shouldn’t restrict access to data or key functions.
Nothing in the system should happen that can’t be replayed, audited and tied to a responsible party.
Prototyping - Iterate and improve frequently
We believe in designing via working prototypes, rather than using static design tools. This encourages engineers to be multi-disciplinary and get involved in a hands-on manner in prototyping, learning the lessons first hand. Agile supports rapid prototyping well, because it lets us try, fail, learn and adapt in quick cycles before moving towards a final solution for a feature.
Agile is right at the heart of our prototyping and building process.
The key principles of agile delivery at Purepoint are:
- Satisfaction through early and continuous delivery
- Requirements evolve, but the time scale is fixed
- Collaboration between stakeholders throughout the entire process
- Support, trust and motivation between all involved
- Working solutions are the primary measure of progress
- Self-organising teams are more agile, responsive, and encourage consistent delivery
- Simplicity & the 80/20 rule
Prototyping - Do ongoing user research
Something often forgotten in software design is the importance of continuing user research throughout development. The nature of agile means requirements change, and solutions change, so we need to continue to test and challenge our assumptions and solutions as those changes happen.
Building – Visibility
If a tree falls in a forest and no one is around to hear it, does it make a sound?
To deliver in an agile manner, and with confidence visibility throughout the project is pivotal. This means open communication channels, open access to tools and systems, accessible staging servers and document repositories.
There isn’t such a thing as too much transparency of visibility when it comes to delivering software.
Building - Accessibility and assisted access
In the UK 1 in 5 people have some sort of disability. It shouldn’t be an afterthought to service these users at the end of building a solution. Accessibility goes far beyond just people with disabilities though, users could have limited internet connection, be in a distracting environment, or using outdated hardware.
The minimum compliance should be:
- Comply with the Web Content Accessibility Guidelines (WCAG 2.0)
- Build compatibility with the most common assistive technologies – screen readers, and speech recognition tools
- Build compatibility for users who don’t use a mouse or touch device
Delivering - Open Source where possible
Identifying components that could be open sourced up-front is really helpful. It’s easier to work open-source on something from the start than it is to retrospectively turn into an open source project. Working in the open helps you devise standard interfaces, write good documentation, keep data separate, and get the process for integrating open source into your main project in place.
We can’t always produce open source components, it depends on the licences and contracts agreed upon – but it is without a doubt that the advantages open source usually outweigh the disadvantages.
Delivering - Monitor performance indicators
It can be difficult to see the value a project is generating, especially when it is in its early stages. Being able to see hard numbers and results can go a long way towards getting stakeholder buy in and adoption. Information dashboards or regular reports are an excellent way of sharing KPIs with stakeholders.
Key performance indictors to consider are:
- Goal completion rates & routes
- Failure rates
- Process overheads
- Cost per transaction
Delivering - Measure Success
To really know if a project was a success we must have clear goals, and data to validate them against. Measuring satisfaction, adoption and ROI are all important parts of deciding if a project has reached its goal yet. In an agile process this is a continuous challenge, and there is always going to be room for improvement.