Note about this chapter:
The chapter still uses the first version of the “Attractors” at most places, since then I completely revamped that list, but didn’t fully update this chapter, yet.
- All the practical tools we have to influence the elements of the User API.
Quite a few previously discussed topics will finally connect together here. It's going to be an interesting part. Looking back, In Chapter 2 you already learned about the 7 factors of commercial software aka the User API. Most recently you saw the overview of CX and the high level definition of user value. We will start working with these to finally see exactly how we come to the picture.
Here we will examine each point closely and see how do they fit with the new things you learnt. Understanding this is core to the message of this book, because this is what's in our - more or less - direct control. The main connection between this API and the Financial is CX. Keep this in mind because you can find all the connected business values through that. We will go into the details analyzing what are the exact elements of CX at play. That means the parts of UX, CL and the Attractors. Here, I will finally use some practical examples from everyday development work to show how we actually affect these.
From the UX perspective this category is closely related to the useful and valuable facets. I think the relationship is quite clear, usefulness is a direct derivative of having the right functionality and valuable is mainly fueled by having a market need for the product and that is again based on functionality. This is the most direct manifestation of the problem ←→ solution aspect of software.
There are three connections between this and the attractors. To understand them we need to start expanding on our high level user value definition. The first point we made was users like getting what they want. That means lots of things, but in essence they want the solution to their problem, that translates to the right functionality for us, and they want it as fast as possible, with minimal effort from their side. These are the keywords here, speed and convenience. This shows how functionality is intertwined with UX. For this case, the connection with the attractors is already laid out, did you notice? The culprit is fast. Functionality can affect the speed of usage. That influences the high performance, easy to access and pleasant to use attractors. There are multiple ways to offer the same functionality and from a technical perspective they can be totally different things. Like offering a payment method, supporting credit card or PayPal or Bit Coin are 3 totally different things from our perspective. Their implementation would have little in common besides some records in the DB or high level APIs. So in summary choosing a different kind of solution to reach the same goal can speed up the users' workflow. They don't just want a certain functionality they want the right kind of it.
The second value is convenience. That is related to both the high quality and user friendly attractors. If we mess up the implementation and the functionality gets buggy that will deter these factors. Utilizing all our professional knowledge to deliver stable and bug-free software is the way to maximize the benefits of functionality.
The third one is simply the existence of functionalities. This can affect all six attractors, cheap, fast, high quality, luxurious, user friendly and customer service. A focused, non bloated product can be developed for a lower price so the user can get it cheaper. Offering only the minimal necessary features makes sure that performance doesn't suffer thanks to simply the size of the application, that means a fast software for the users. If you spend time on refining a small number of core features instead of adding in new ones all the time, there's a higher probability that the resulting software will be of high quality. If the functionality enables some kind of extravagant activity, like ordering a private helicopter to your garden it will definitely change how luxurious the product looks like. If the users are not lost and confused by the sheer number of items in the menus or by the amount of shortcuts to learn that contributes to making the product user friendly. On the contrary though, if some functionality doesn't exist that the users really want it can negatively affect the perception of both the high quality and user friendly attractors. Finally, the added new functionality needs to be supported by the company and if the staff is not prepared to do that or it takes a long time to resolve initial problems after release it will create a bad impression about the quality of customer service. As developers we should be able to tell when will the addition of new features start to negatively affect the performance of the application and when it's best to focus on refining the implementation of existing ones. This is a responsibility only we can fulfill.
These connected attractors show that more parts of UX are at play here. Speed and convenience belong the usable and desirable facets. The number and type of existing functionalities can affect usable, desirable and findable too. This is interesting, we are looking purely at functionality and suddenly you might think:
You just didn't know yet. There's simply no way to detach the experience from functionality in the user's perspective. So why are we talking about this separately? I guess it's more of a rhetorical question. During everyday work we do lots and lots of development that only indirectly affects UX and either because of this or simply because we don't need to care, the consideration about how the implementation will affect the user experience is neglected but the feature itself obviously gets thought through. So the separation exists in our minds but not in the reality of the users. They are simply different considerations for us, but in reality Product == UX! When referring to UX in this sense I will use the term Holistic User Experience or HUE.
This is reinforced by the fact that functionality is also the foundation of success throughout all phases of CL. Starting with awareness it offers the features to advertise. At engagement it is less relevant but through contributing to the success of the company it affects their public perception, so in a positive case it means the feedback available online is more favorable, making a better impression in the potential customer. Functionality is also a main factor at evaluation, much less during the purchase. It's again really significant in the experience of the product and only indirectly involved with bonding, but it's still a prerequisite for that. As developers defining functionality is usually not our main domain, however if you are working on your own side project it's very good to know these relationships to see all the possible consequences of implementing your ideas. In case of working in a purely developmental role you can utilize our unique insight to offer ideas of new functionality or change or re-prioritize existing ones and base your suggestion on all the possible business outcomes you learned about. There are situations when choosing a certain technology for the job, leads to the redesigning of some existing or planned features because either the lack or the existence of capabilities in the new tool changes what was thought to be possible. These connections help in evaluating the results of each alternative.
This is going to be the topic where we will spend the majority of this chapter because this is our real home as developers out of the seven commercial factors. It might sound contradictory at first but believe me, it's true and you will soon see why. UX is a central factor in many of the attractors so it's crucial to get it right. For software it is a force behind high-quality, user friendly and luxurious. In a less traditional way it's also responsible for the fast category and the resources spent on it can affect the final price of the product. Then the obvious question is: what makes great UX? Let's explore how the facets of UX manifest in software. We will skip the ones not relevant to a developer's job. Our main area of concern is:
Let's define it precisely this time, unlike with the vague description I gave in the previous chapter. It's important to understand what are we dealing with because it's the biggest part of our role in delivering UX. The definition I like the most puts usability as the union of three dimensions. When the software is all at the same time efficient, effective and satisfying to use it is ultimately usable. Of course usability is a spectrum and no application have to be perfect in all senses to make an over all really good experience. The first element of usability is efficiency. It means the user can do what they want with the speed they prefer. Second is effectiveness, it means how much better can the user achieve their goal by using the software than without it. Or you can make other products and even earlier versions as the reference for comparison. Finally, satisfaction summarizes the impression of individual users about their usage of the product. These might seem quite far from what developers can affect, so let's dig deeper. The key is to understand the part about they can do what they want with their preferred speed. Intuitively you might think about ease of use, and while that is a good optimization goal for UX, it's not the point of effectiveness, so let's address that. How easy-to-use a software can get always depends on it's business domain. When you are creating software to work with incredibly complex real life problems, that will inevitably get reflected on the product. So the users' expectations about the level of easiness is usually proportional to the complexity of the job they are doing. Efficiency should be a higher priority goal for all software. While the main gateways to efficiency are good business modelling, natural workflows and intuitive user interfaces, there are other aspects in play and those will lead to us. Our unique responsibilities are performance and stability. They have a crucial part in providing a good UX. These worth separate books on their own and are also platform, language and framework specific so I will only give a general overview. I think we are all too familiar with the ways how buggy, crashing, or lagging, slowly loading programs can ruin even the nicest experiences. So the implementation can make-or-break the vision created by the designers. We will now zoom in on both categories and I will explain in how they affect UX in practice.
Loading and saving times are the enemy of users. Nobody likes being blocked from getting things done so do loading on demand, in the background whenever possible. The subject of loading can be many things like resources, assets, UI elements, views, pages, even updates or the download of whole applications. Prefetching and caching considerations are exclusively our domain just as batching, deferring or parallelizing the different tasks. This is one if not the most important contributions to UX we bring to the table as it is solely in our field of expertise. Saving can also be done asynchronously with optimistic local updates on the UI level to provide a great experience.
Responsiveness is a must have. The RAIL model developed by Google gives good guidance here. I recommend learning that for every developer. Even though it's web focused, the performance targets are based on the characteristics of human perception. Here are the main takeaways from there. If we want to make the users to feel their workflow uninterrupted and continuous, the maximum delay between the different steps, like navigating views or submitting forms, is 1 second. Whenever the users interact with the software we have a roughly 100 ms window to react, without negatively affecting their sense of performance. This means in many cases the real time frame we have is even smaller as the runtime and OS has it's own things to do and their overhead should be accounted for. The exact numbers are always specific to the target software and hardware environment. If you wonder how the reaction to user input and the steps of a workflow differ, think of them as the time we have to start an operation after the input event and the time we have to finish it. In case of animations, 60 fps is the standard goal because we are really good at noticing stutter. To reach that we have 16 milliseconds for delivering an update to the screen. This again includes all the overhead processing so the real budget we have for our code to run is less than that.
A related concern is performance testing which is a huge topic on it's own, all we need here it to note it's also an important factor in ensuring consistent high performance on the long run.
In general ensuring top performance that doesn't degrade over time is one of our most important task and it involves a large variety of specialized knowledge. Make sure to learn the details of the environment you are working in to ensure great UX. A final advice from me as a frontend developer, always keep in mind that performance doesn't equal perceived performance. There are some tricks to make slow processes feel fast(er). When in doubt consult your UX or Interaction designer.
This is the most obvious from all our unique responsibilities. Shipping stable software means it's bug-free to the greatest extent we can reach. It doesn't crash but when it does it fails gracefully. That means it isolates the failure to affect the smallest part of the application possible. It always shows meaningful and actionable error messages. Offers ways to resume from an error or show where to find help. I generously skipped the details about how to deliver as few bugs as we can manage. Along the way you will see some useful generic ideas but because it's also a technology dependent topic, the specifics are out of scope of this material.
There are a few related practices we are doing regularly. Refactoring is one example. It should happen transparently to the users so they only see the benefits. Rolling out new versions should always result in working software for the users, no matter where they are upgrading from or what is cached on their systems which can be especially challenging for web applications.
Keeping in progress work saved, account and personal information persisted across updates, restarts or other changes also help with providing a stable user experience.
Making sure that system resources are properly handled to avoid crashes over long periods of usage, taking care of exceptional use cases and the many different kinds of software testing all contribute to stability. Most commonly we are involved in implementing unit and end-to-end tests, but reliability and regression tests are even more relevant here.
There are two closely related categories that are not universally applicable but important enough to discuss them separately.
- Availability When talking about availability we have to first clarify that it's only relevant for distributed systems or software with some kind of external dependency, like a machine that is not always operational. So availability is not a property of software itself, it applies to whole IT systems. An easy way to define it is by a percentage. Usually it's about the time while the users are able to use the systems vs not over the course of a set period. Software is often the cause of losing out on it, but hardware issues can hinder it just as badly. When we narrow our focus to the software level, all availability concerns transform to stability questions.
Designing high-availability systems is a different skill than designing stable software. It's about choosing the right structure for the system, the right components for each part of the solution and the type of connections and communication between them are also major questions. I consider availability a superset of stability for distributed systems.
Common related practices are ensuring scalability, setting up backup routines and implementing failure detection and auto recovery mechanisms. Validating this property of systems can be done via load testing, chaos engineering or traditional availability testing among other methods.
This plays a major role in providing high quality UX as an available product is the prerequisite to even have a real user experience. Not being able to access the software is still an experience, just not the kind we are trying to actually provide, but similarly to the case of stability, the applications should be prepared to gracefully handle this kind of situation because it's inevitable in practice for most IT systems.
It's an an aspect that can ruin the satisfaction of the users very badly but the probability of that happening is usually much lower than with the other stability factors. Security is concerning the critical information that is stored in the systems, usually it's access credentials, personally identifiable information, financial data, or private content. When unauthorized access is gained to these that's a security breach. Of course no user is happy when that happens.
All right, I was stating the obvious, what's interesting to notice is that increasing security many times comes with a trade-off. It usually includes adding extra steps to the workflows and extra processing steps to the handling of data. Both of these degrade the usability of the software. Our responsibility is again to deliver performance, while maintaining a proper level of security.
Much like with all the other aspects we discussed it's implementation is environment specific. Many times a separate field of expertise on it's own, however the goals of software security are always the same, identifying critical data and ensuring proper access to it. I can only encourage you to learn the details relevant to your work to cement the UX of the product.
Our role in usability can be neatly summed up in one principle. Do not disrupt usage. Or minimize it to the absolute necessary. This way you deliver the best possible UX. To make it more memorable I like to call our unique responsibility in providing usable software PASS. Performance, Availability, Stability, Security. With only a little bit of stretch to the meaning it also makes sense, we enable the UX created by the design process to manifest unhindered in the software by maxing out these 4 areas, or put otherwise we let it to pass through development to the user.
This one is a very short section, because most of the findability concerns are really matters of design. The only purely technical aspect is search engine optimization for web sites and applications. It's an important component of financial success because it gives a huge boost in the awareness phase of the CL and helps in the evaluation part as well. For non-web applications there are still some findability concerns but only in a less traditional sense and most of them are really obvious. In the case of open source libraries it's important to be published through a popular package manager, for plugins to be uploaded into the vendor specific repositories instead of self-hosting for example. In general, make it easy for the target audience to find your product.
You can also consider the available documentation a form of supporting internal findability for applications, and both external and internal for developer targeted software like frameworks or even APIs. So by publishing high quality instructions you gain the same kind of advantages for your project as SEO offers for web apps but with a smaller impact.
In terms of attractors our part here doesn't map to them straightforwardly. It definitely is something the users desire but is it covered by any of the 6 points? For classic internal findability it would clearly mean user friendly and high quality, but that's purely an UX matter. I think about the developer part as a form of customer service. The users have a question they need the answer for. Where is X? Or how does Y work? In a physical shop they might ask an employee or look for signs. The kind of findability we can provide is like a book or machine at an information stand where they can find the answer themselves. So I consider this a kind of self service and when that's done right it adds to the overall user satisfaction.
This is again an environment specific concern from our perspective. The closer your work is to the UI layer, the more likely you might need to deal with this aspect. The key areas in 2020 is to provide screen-reader support and the ability to control the application with only the keyboard or voice commands. Less common considerations are providing alternate high contrast or static interfaces for visually impaired or motion sick users. There's a term that when technically speaking is a separate category, internationalization, however from the perspective of user experience this is an accessibility concern as well. It can enable people to or deter them from using our products.
The value it provides by CX is the same as usability offers, because for the disabled users accessibility is a prerequisite for usability. Furthermore this is the only facet that affects another element of the Financial API. It opens up a new market segment for companies so it creates a business opportunity as well.
Because the existence of accessibility solely depends on the implementation it's our unique responsibility to address it.
Credibility is similar to usability the a sense we aren't the ones who create it, but we can hinder it pretty badly. I will focus on the mistakes we should avoid doing. In the worst case we can create, the users won't believe the software they use is legitimate. That's hard to pull off without serious design mistakes though. The key components of credibility are trust and identity. It works very simply. The customers trust a brand and the brand's identity is strongly reflected by the software. So how do we mess it up? Usually by rookie mistakes.
- Remove placeholder data
- Remove visible debug information
- Remove dummy behavior
Messing up the default configurations like:
- Metrics & formats
Other kinds of less common issues that can happen:
- Getting falsely identified by antivirus programs
- Listed as untrusted software by the platform or OS
- Actually getting hacked and delivering malicious code
- Software instability leading to lost work (worst example: Windows 95 crashes and restarts)
If we make too many issues like these, the users might start to question the legitimacy of the software. Luckily a few cases only appear as bugs, just don't ship a whole constellation of them and credibility most likely won't suffer. It's not that hard to avoid these kind of problems yet it happens occasionally, make sure to double check.
The value of credibility comes from enabling the other facets to manifest their positive effects. Nobody will feel like "Wow, this app is so credible, I need it!". [Nobody ever or such wow meme] However if we start to damage the trust of the users, they might became unsatisfied or outright turned off from using it.
All aspects of user experience affect the steps of CL in a very similar fashion. Doesn't matter which facet are we talking about, if it gets improved it will contribute to awareness by better word-of-mouth recommendations and online reviews about the product. It will add or reinforce advantages of the software for the evaluation phase. Obviously offer a better experience while using the software and if the quality is kept on the long run then contribute to successful bonding.
This is an intrinsic attribute of software development, and I didn't really see a consensus forming on what would be the ideal value for it. In the enterprise agile land the two week sprint is the most standard, but with the CI/CD approach daily deploys are also a popular alternative. In other domains like OS or firmware development it's a totally different game. Nonetheless, whatever is the interval used, there are many benefits of releasing software as frequently as possible, assuming the new versions actually deliver value of course. I think we all know the feeling when a program just gets worse and worse with each update, it's not nice and doesn't help our business. However, in the positive situation our users are going to be happy because:
- Of the positive effects the various changes bring to the table through HUE.
- They will be more engaged if the changes address the problems they faced.
- They will feel that the company cares about them if their feedback has been taken into account.
In terms of attractors this counts as customer service, as we are serving their requests in the ideal case. From the CL phases it most heavily affects bonding, as they already need to be customers to experience these first hand. However that's not all, as with all bonding improvements it will result in better reviews and reputation so it creates increased awareness, bringing in more new customers. For many of us the level of care from the company and active development of the product are important factors at the evaluation step, so it's another benefit.
How do we affect it with technology? First of all, the release frequency is mostly an organizational and workflow matter, but the used language, framework and most importantly their tooling has a part in the frequency we can pull off. I don't want to go too deep into the factors that are further away from development, but because they can affect our workflow in a major ways, I included a description of the big ones.
If you develop control software for space rockets or a mobile game your release and update schedule will be vastly different. When working on software that is mission critical, meaning human lives depend on it, the measures in place for ensuring safety will add a huge overhead to your release schedule. The validation, verification and quality assurance processes can take a lot of time, but the user expectations are usually aligned with the common delivery times of your domain. If you can deliver push updates or simply release a new version to download from a website or package manager your release frequency will depend on factors that are not that impactful for other kinds of software, like large scale infrastructure as a service systems or banking solutions.
Architecture and infrastructure
This is mostly the concern of typical enterprise and/or distributed systems. The architecture of the components is a serious contributor to deployment speed and schedule. Infrastructure is an inseparable part of that and goes hand-in-hand with the design of the systems. Do you need to stop services from running to update or upgrade them or do you have some mechanism to mitigate that issue? How long does an update take? How many parts of the system does it affect? All of these and more are dependent on architecture & infrastructure. If the time necessary to release a new version is as long as a couple of hours and the system needs to be taken offline of course you can't release software every day, that would be a serious outage.
The tools and processes used to deploy the software can also have a huge impact on what frequency is achievable. The most important factors in 2020 are kind of common now, which is a well set up CI/CD pipeline with everything needed, version control, build system, deployment and backup automation. Again it only shows how it makes a real difference if we take a look back on earlier times, when these techniques were absent.
The most important, exclusive way we can improve this area is quite unsurprisingly developer productivity. Whatever helps with that helps to increase the speed of delivery. It's a very complex topic that we will explore in detail in Chapter 11, but to offer some practical examples I promised, here are the 3 most important aspects.
High code quality to improve maintainability
- Good separation of responsibilities
- Project standards
- Project structure
- Thorough testing
Anything that helps to see the effects of your work faster
- Reduced build times
- Live reloading
- Better task automation
Whatever improves the debugging workflow
- Better observability
- Remote debugging
- Better logging
These really are just a few examples of a major topic, but I hope they help to understand the mechanisms how the tech choices affect the users through the release frequency.
This is the bane of many developers. What can be further from our magic research lab than the mundane problems of everyday people? That's the attitude I often see. Honestly, it's understandable this is the situation. As developers we like to and have to deal with things that are very different than human beings. Computers and code are more-or-less under our complete control, they do whatever we tell them to do. They are deterministic and can be understood with clarity. Programming is a rigorous and well structured process with strict rules to follow, yet with endless potential for creativity. Well, I don't think I have to point out the differences compared to interacting with people.🙂 Even so customer support is a very important factor in running a successful business. Whether you need to do it yourself, issues get escalated to you or only the bugs to fix in the next iteration, we affect this area on many levels.
Starting with the business value part, it's immediately clear that it connects to the customer service attractor and to the experience and bonding phases of the CL. When you are in a position that includes offering direct customer support you picked up a new hat and with that a new profession. How to do a stellar job as a support agent is out of our focus here, also lacking from my personal experience but the attitudes you saw as details of user value can offer some guidance. Nonetheless we have a little influence on the agents' work even when we don't get in touch with the users ever.
The most obvious is knowledge transfer. This might happen indirectly but many things about the working of the software they have to support is only known by the developers initially. If nothing else then the list of known bugs and quirks are really good to get documented. Speaking of documentation, in some jobs you might have to take part in writing the user manual, or change logs and those can be of interest to support agents. It's the same with feature roadmaps and development schedules.
Going closer to the technical stuff, we are usually needed to either troubleshoot or resolve user facing issues. Hopefully the agent or you can gather all the reproduction steps, and the context of the error. Here comes a unique responsibility. Can you guess what? Only we have the knowledge to analyze the inner context of the issue, meaning the internal status of the software and/or system. The extent we can access that is in huge part depending on how well we designed the application. So logging, error reporting, crash info gathering, performance monitoring are all things that, if we do right, help to resolve our customers' problems. It's worthwhile to think about them in advance and release software with these implemented properly. The last and most obvious responsibility we have is to actually find the cause of and fix the issues. Anything that makes you a better developer is relevant here. The last, invisible kind of support we can do is implementing automated testing of the product to eliminate issues before they cause problems to the users.
I guess by now you are far past the point where you still needed help to realize the connection between the User API and the factors of CX or business values. So I'm sorry if it got boring but I want to do a through job. Let's see how does price work from the business perspective. This is a derivative of how the 4 effects are affected. Each of them has a way to influence the price of the software. The key is supply, demand and profitability. This is true in general for any kind of product. In our case, productivity maps to how efficiently we can supply the software, going out faster and/or delivering more. The central role of CX in this sense is to increase demand. Finally utilization together with productivity are the way to increase profitability. The business opportunities can contribute to lower prices by increasing sales volume.
From the attractors of course, cheap is the most directly linked factor but in reality all of them are connected. If you want to make improvements to the other elements then that will come with additional costs. This is the well known trade off between the price and other qualities of a product.
It's role in the CL is most important at the evaluation phase and it contributes to the overall satisfaction of the users, contributing to bonding.
It might sound a little weird, but I consider the purchasing of a product the part of the user experience it provides. In this sense, I think the price is connected to the accessible facet, as it can prevent people with low income from being able to use the product.
With all that covered, let's see what do we have to do with it. The first thing we need is to understand the factors affecting the price of the product. Of course I will focus on what's connected to our work. Influencing the demand for our product is not really a developer concern, but the other factor of price which is the total cost of producing the goods is much more relevant. From economics 101 we know that total cost (TC) is made up of two parts the fixed and variable costs. The first part includes the things that are constant whatever amount of the product is created. The second of course is what scales with the produced number. Two examples of fixed costs would be rental fees and cost of services like security or insurance. The most significant variable cost is wage as the volume of labor scales with the work needed to be done. Raw material costs are also included here, in our case license fees can be considered that. The relationship between TC and price is quite clear to everyone. It's obvious this is where our choices can make a huge difference. The most important factors are productivity and utilization.
We can achieve that by reusing existing solutions, choosing services that offer better pricing than our current solutions, investing in training of developers, using the technologies that fit both the workforce and project or adopting new more efficient tools. All of these are specific to every situation. However you will learn later how to analyze their most important aspects in the chapters about the organization.
Users usually form online and sometimes offline communities around products they like to (or need to) use. By facilitating this, the company can make a real difference in engaging their audience. Let's explore the business aspects. Having a community plays a role right from the start in the CL. It can contribute to raising awareness of your product by the online and real-life exposure of the groups. Checking the company interactions in them is a valuable source of information during the engagement phase. Their level of activity and offered support can be a critical part in the evaluation. In some situations it plays a huge role in supporting the users so it can be a significant component of the experience step. Most importantly it can be a great tool in creating those long lasting bonds with the customers.
From the attractors it's most closely matching the customer service and a little less with high quality.
And how do we affect it with technology? Only indirectly, this is a field in the User API where we have little influence. By implementing the necessary platforms and integrations we create the environments for a company hosted community, ensuring it's stability constitutes to it's success. But these are not development choices. The groups will however reflect the results of our decisions. The issues about the software can surface there just as the positive aspects. It's a hugely valuable source of feedback to any business. It's a good practice to get a few representatives of the development to actively engage with the community through these groups or events. I think in general game developers are doing this the best right now. Being in direct contact with us gives a sense of importance to our users or prospective clients. It creates the sense of us caring about them, that their opinions are valuable and will lead to action. So new hats up fellow developers! 🤠 This way we can greatly increase customer engagement, bringing along all it's benefits. How to build a great community is a separate art, but the main components are honest and positive communication, an open, helpful and welcoming culture, clean guidelines and code of conduct, thorough moderation enabling a high level of psychological safety and also humor is a good ingredient in most situations.
We already saw quite a few ways of gathering feedback in this chapter. Do a quick recount. We talked about many technical practices that I consider as forms of internal feedback. They were:
All forms of it including performance, availability or network.
Again all forms of it like unit, integration, end-to-end, stability, regression, performance, etc...
For all events we consider significant in the life of our software
We also spoke of user feedback in various forms:
- Built-in error reporting
Where it's possible of course, many types of software can't have this option
- Direct customer support
Through any kind of communication channel: chat, email, forum, on-call
- Community involvement
Be that either company hosted or external, interacting with our users can offer a lot of insight
By all these means we get to see what happens during the usage of our products and how that affects the users. Testing is a bit of an outlier here, as that shows the same things but during development. There are of course other, more direct ways of getting feedback from the users but I consider them the domain of marketing and UX. We might need to implement a few forms, or email templates for that but that's not really a tech decision. A more relevant question is, how does it affect the business? It depends on what do we do with it. There are only two options. We either act upon or ignore it.
When we choose the first option we align the product to the real customer needs. That has benefits on many levels. In terms of CL it will lead to better reviews and word-of-mouth so better awareness. They also form a better image of the company, so it contributes to successful engagement. This can be a deciding factor for conscious consumers in the evaluation phase. And finally it's also a major part in bonding. From the attractor's perspective it's can best matched to customer service just as with community, but in this case, by making use of the gained insights we can increase any of the other factors.
In the case of ignoring the feedback we simply create the opposite effects. It's common sense to do everything we can to get feedback and incorporate it into our products.
What's our role in gathering and using feedback? This is the last in the API because we got it all covered already. By making sure that the technical feedback tools are properly put in place and we are prepared to step into another role, our part is done here. The takeaway is whenever you can, try to encourage the collection of feedback and use it to improve the product.
This is going to be an excerpt from the current and previous chapters to help with seeing the big picture without losing the details. Its goal is to show you how our work affects the users and in turn what are the expected business outcomes.
Strongest Business Effects
- Choosing the best technical solution for the specific user needs. - Prevent ruining the functionality with bugs. - Protect the performance by keeping the application functionality to only what really matters.
Direct - 3 Direct - 3 Direct - 2
- Useful: The basic source of usefulness is the functionality the software provides. - Valuable: How much value can the software produce depends a lot on how strongly do people need the functionality it provides. - Usable: It's possible to offer the same "functionality" using different solutions. Based on how fit they are to the real life tasks the usability of the software is influenced.
Direct - 3 Direct - 3 Indirect - 2 Indirect - 3
- Evaluation: The features offered by a product is usually the main evaluation criteria. - Experience: Maybe half of the user experience is the functionality itself. - Bonding: If the product serves the customer needs, that's a major part in forming a lasting relationship. - Awareness: As it's a really strong factor in other areas it's effect will ripple back to generating better word-of-mouth recommendations and awareness.
Pleasant to use
Easy to maintain
Direct - 3
- Feature match: The offered features are half of the equation for this attractor.
- Increased revenue - Increased customer satisfaction - Entering new markets
- Usable: Do not disrupt usage. Let the designed experience pass through development unhindered, by maximizing: performance, availability, stability, security. - Findable: Implementing good SEO when relevant. Publishing the software through popular platforms. Writing good documentation. - Accessible: Implementing the technical solutions that enable the usage of the product by the intended user groups. Minimizing costs of the product. - Credible: Properly remove dummy implementations used during development, using the correct configuration for each user/customer, avoiding security issues
Direct - 3 Direct - 3 Indirect - 2 Indirect - 2 Direct - 1
Pleasant to use
Easy to access
Effective visual design
Direct - 3 Direct - 3
- Increased revenue - Increased customer satisfaction and retention - Accessing new market segments
- Choosing tools and infrastructure that enable the fast releasing of software. - Setting up the workflow and organizational processes to accommodate frequent releases. - Getting the necessary resources like developers, licenses etc... to eliminate bottlenecks in delivery. - Increasing developer productivity to maximize the possible frequency.
Direct - 2 Direct - 2
- Useful: In terms of purely release performance, discarding any benefit the software itself might deliver, having frequent releases makes the product more useful compared to one which don't have it, simply because the pace of changes leads to better product-market fit. - Valuable: The same mechanism also leads to increased value for the stakeholders.
Direct - 2 Direct - 2 Indirect - 2
Easy to maintain
Easy to access
Professional customer service
- Easy to maintain: Delivering high value and frequent updates is the primary way of influencing this attractor through purely technology.
- Lower risks - Lower cost of delay - Customer retention
- Improving CX to increase demand. - Lowering costs through increased utilization and productivity. (Hopefully increasing the produced value for the same price instead of removing jobs or decreasing salaries) - Using development tools, services and platforms with the best pricing option. - Reuse of resources like existing code, tools and skills. - Writing reusable and maintainable code. - Training the developers. - Using tools that fit the organizational resources.
Direct - 3 Indirect - 1 Indirect - 1
Price to value ratio
- Price to value ratio: This attractor is affected by every element of the User API as each of them offers value, yet I only list it here because it makes the most sense.
- Number of sales - Increased market reach - Enabling economies of scale
- Implementing monitoring, logging, error reporting, automatic recovery. - Debug and fix the issues. - Implement automatic tests to prevent the issues.
Indirect - 1
- All: Has the possibility to indirectly affect any UX category by fixing detriments.
Direct - 2 Direct - 3 Direct - 2 Indirect - 2 Indirect - 2
Professional customer service
Easy to maintain
- Easy to maintain: Support is in itself a maintenance activity albeit not a technical one.
- Customer ~ loyalty, engagement, retention - Lower cost of customer acquisition
- Implement the functionality for gathering feedback - Gathering feedback first hand by getting into direct contact with the real users through support, community engagement or events.
Indirect - 2
- All: Has the possibility to indirectly affect any UX category by gaining new insights directly from the customers about where and how to improve the product..
Direct - 3 Direct - 3 Direct - 3 Indirect - 2
Professional customer service
Easy to maintain
- Easy to maintain: A company that is receptive and responsive to feedback will have much better product-market fit on the long term, this way will support the evolving customer needs more efficiently.
- Costumer ~ loyalty, engagement, retention
- Implement the platforms, integrations and tools to facilitate the user communities. - Directly take part in those communities.
Direct - 3 Direct - 3 Direct - 2 Direct - 2 Direct - 3
Professional customer service
Easy to maintain
- Easy to maintain: As the communities can offer a form of product support it transitively delivers on this attractor as well.
- Customer ~loyalty, engagement, retention
I want to conclude this chapter by finally defining user value from our perspective. User value is anything that improves on the elements of the User API. For us that covers all aspects of the work which provide the high level user values defined in the last chapter. I think it's pretty neat, we identified everything we need to consider when trying to make our products appeal to the users and now you know about all 7 of them!
Bonding is an interesting case. This is the number one most important business goal for many companies and the whole point of bothering with understanding the customer lifecycle. Yet, we can't really influence it directly by only working on software. This proves that software is just a tool, in reality we are trying to form business relationship with real humans. In order to do that, we can contribute the most by putting emphasis on the parts where we actually get into contact with them. Support, feedback, release performance and community. This is their order of relative impact. As the current generation of technologies mature and improving the user experience starts to have diminishing returns in order for businesses to succeed, attaining customer loyalty is getting even more important. I think we will see more and more emphasis on building up this kind of relationship even within the software development discipline. A good example of this already happening is the rising number of Dev Community Manager, DX Advocate and similar positions that all try to engage the customers (us) of the dev tool companies to increase bonding and gain bigger market shares.
The developer's responsibilities Functionality: Delivering consistently high-quality, bug-free features. Choosing the technical solution for a given problem that takes the least effort from the users to conveniently and efficiently get their job done. Keeping the number of features to the minimum that adds user value. We are the only ones to know what's the threshold before the speed would suffer so challenge the feature ideas and use our unique insight to offer alternatives. UX: We have a direct role in 4 of the 7 facets. The most important is usability. Our job can be summed up in a single sentence: Do not disrupt usage. Our role is to manifest the designed UX unhindered. We need to let it PASS development. That stands for Performance, Availability, Stability, Security. The aspects that can ruin a smooth experience and the aspects only a developer can affect. The other three are findability, accessibility and credibility. Their respective main technical concerns are: SEO and online access, keyboard and screen-reader support, bug-free and brand conforming software. Release performance: There are 4 main factors affecting the highest achievable performance. Criticality: How secure and correct should the software be on release. Architecture & Infrastructure: Both the software and hardware choices can make a huge difference here. Deployment: The tools and systems used for handling the deploy processes. Productivity: The most directly influenced field, whenever we speed up the work it contributes to enabling frequent releases. Support: Our involvement varies a lot by the job and company but we should share our knowledge about the usage of the software with the persons offering support, including the list of known bugs, available documentation and manuals, release notes, feature roadmap etc.. Implementing proper logging, error reporting, crash info gathering, and performance monitoring help to offer support. Lastly we are the ones to fix the reported issues. Price: Mostly our part revolves around lowering the costs of development and maintenance. Productivity and utilization improvements are a main way of doing this, but the choice of used 3rd part solutions, whether a library, a cloud platform or anything premade can affect the costs a lot. Community: We might need to implement company hosted online environments like forums, or integrations with tools like Intercom or Slack to facilitate these communities, but our direct involvement in them also creates benefits to the companies and users alike. Feedback: Our influence here is through the technical feedback: monitoring, logging, testing and error-reporting. In a non strictly developer role you can try to reach out the users directly using any communication channel, most commonly email.