We solve problems every day. We have ideas and a desire to make things better. The solutions we create may seem mundane or even profound. They may not support monetization, contribute to a corporation’s bottom line, or raise a society’s GDP, yet that doesn’t reduce its value or significance.
We create, but sometimes our creations create more problems than they solve. I’m not necessarily talking about solutions that are harmful by design (e.g., cigarettes) or promote injustice (e.g., gerrymandering and bribery), but those unintended consequences that so often arise. This may be called disparate impact in the workplace, side effects in medicine, or just another day.
I have been reflecting on my recent experiences in both creating software and creating communities to identify ways to minimize the deficits of our solutions and maximize the benefits. For the sake of this article, I am calling them Five Dimensions of Solution Design. I apologize right now for the alliteration.
- Compliance
- Capabilities
- Capacity
- Communication
- Confidence
Compliance
The first dimension is compliance. While this may have a legal connotation to it, I am considering it in a broader sense. This can include security, privacy, safety, accessibility, and governance inclusive of the relevant laws and regulations, best practices, and standards.
When we design our solutions, whether products or services, we should start with compliance in mind. How do we keep the providers and the consumers of our solution safe? Does our solution create unreasonable barriers for some? Who defines unreasonable?
If you are following my ScriptLink series, then compliance may look like some of the following:
- Limiting Protected Health Information in logs and requiring unique user identification to access these logs.
- Requiring SSL to consume your ScriptLink API (not just moving to port 443).
- Ensuring usernames and passwords are not stored in your source code.
Starting with compliance in mind will help minimize the risks later when it is harder to make changes. Identify people in your organization and your community who can help you identify your compliance considerations.
Capabilities
This second dimension is probably the most obvious. If you have identified a problem to solve and a solution to solve it, then you have to at least minimally answered this question. What does it do? Sometimes the answer to this is so high level that we don’t yet know what that means.
I was once a part of a group many years ago that was asked about the potential capabilities for an upcoming mobility solution for the mental health organization I worked for at the time. I and many others indicated that the one capability the solution would need to have for us to consider adoption was the ability to collect signatures on treatment plans. The solution was ultimately released without that feature and obviously we did not adopt it. It lacked an essential feature.
It’s important to note that the easy features are not necessarily the same as the essential features. In the above the scenario the essential feature was not easy to implement and was likely deemed out of scope for a minimally viable product. What I learned is that minimally viable means that essential functionality or features are present and available at the beginning. They may not be perfect, optimal, or even pretty, but they are there.
Let’s consider the ScriptLink context again. What are the essential capabilities that your solution must include?
- A myAvatar compatible WSDL.
- A host and service capable of securing your solution with SSL.
- Due to the added complexity and cost, it must likely have more than just a Hello, World! alert.
What are the essential capabilities of your solution? How do the compliance considerations inform what is deemed essential? Who are the stakeholders who help define what is essential?
Capacity
When we first implement our idea it doesn’t need to be able to accommodate millions or even thousands, but it does need the capacity for enough. I recently started my new professional life as a remote worker and my home office needs a trash can. 40 gallons would be overkill, but 40 tablespoons is likely not enough.
In healthcare technology, we have often determined capacity based on the number of users within our organization. We resource our network, servers, and software based on the number of users who will be using it. It worked well for us in many contexts, however interoperability is changing this. The demands on our technology solutions may be impacted by those outside our organization more than those inside.
If we consider the ScriptLink solution again, then we realize that capacity is determined more by the activities of the users and the implemented capabilities than the simple user count. For example, you could have 200 users, but only enable ScriptLink functionality on a form used by 6 users.
- How many requests per second|minute|hour do you need to support?
- How quickly does the API need to respond to ensure myAvatar doesn’t give up on the request? (I.e., timeout)
- What resources present the greatest risk to meeting your minimum capacity? Network? CPU? Memory? Disk I/O? Code quality?
In other contexts, it could be the number of seats, parking spots, staff, or critical supplies. What is the minimum capacity you will need to initially solve the problem or take advantage of the opportunity? How easy will it be to scale up as demands grow in the future?
Communication
Communication gets a lot of attention in leadership contexts. I hear about the value of communication—healthy communication—in the podcasts I listen to each week. While a stated value, it often gets overlooked in the early stages of a solution.
You may have noticed references to this earlier. We should communicate with those who know or can identify our compliance needs. We should communicate with our prospective operators and consumers. We should communicate with our stakeholders whoever they may be.
In my earlier example of the mobility product, that group did a great job of soliciting feedback from us, but fell short of implementing that feedback. Granted, we also had feedback that was justifiably dismissed or delayed. We can be demanding customers and consumers sometimes.
As before, what might this look like in a ScriptLink solution?
- Who are your compliance stakeholders? Do they understand what you are building and how?
- Who will be using it? How will they be using it? How can they provide feedback or report issues?
- Where will you document design decisions? The available APIs? How to configure myAvatar to use your API? How to troubleshoot issues?
I like to add to my ScriptLink solutions web pages that provide the documentation for the APIs. It would include the link to the current WSDL and ideally a list of the available commands that can be called and how to call them.
Solicit advice and feedback. Provide documentation of decisions and design. Keep bi-directional communication going with all of your stakeholders. Help them know they are heard even if you choose another path or not adopt their recommendation. Stay connected. Communicate.
Confidence
Each of previous dimensions will have a great impact on establishing confidence in your solution. This dimension demands time. Confidence is gained and maintained over time. This cannot be evaluated in a moment.
This dimension considers quality, reliability, and consistency. All of our solutions will fail at times, but the frequency and trajectory of those failures will inform confidence. How often are our compliance or capabilities compromised? Our capacity limited? Our communication disrupted?
One last time, back to the ScriptLink scenario.
- How often are users unable to complete a task in myAvatar due to a bug, regression, or outage of your ScriptLink service?
- How quickly and accurately can you diagnose and correct an issue identified in your ScriptLink solution?
- What are that greatest threats to confidence in your ScriptLink solution and how can they be mitigated? (E.g., unit testing, user acceptance testing, high availability hosting, etc.)
I have found that reputations and confidence are not maintained by perfection or even necessarily having the best solution. Confidence is instilled by consistency over time. Is the outage the exception or the norm? The slowness? The attitude? The silence?
Bringing it together
We all have bad days and we all create imperfect solutions. However, we can strive incorporate these dimensions as best as we can with the time allotted.
- Does our solution provide the essential capabilities consistently? Not perfectly. Consistently.
- Does our solution meet the minimum compliance requirements? Can our stakeholders trust that we will consistently give our best to protect them and keep them safe?
- Do we know what’s working well and what is not? Are their stakeholders who have stopped speaking or were never invited to speak in the first place?
- Can we sustain our current capacity level? Is it too little or too much? Too expensive? Under resourced?
With our current global challenges, a sixth dimension for consideration has been underscored. It overlaps with many of the areas above and fits the alliteration: Compassion. Arguably this ought to be the foundation for each of the above.
All too often we can be so consumed with our agenda, interests, and fears, that we lose compassion for those impacted by our actions and inaction. It is important to remember that people the solution is for are more important than the solution itself. Serve the people before the solution. Make sure the solution helps more than hinders or harms. Be patient. Be humble. Let’s save lives and livelihoods together.
What are your thoughts? What other dimensions would you consider when creating your solutions?
Rarely Simple 