Design Thinking – when somebody else designed it
While every organization is unique, those differences do not always justify the investment and upkeep of customized software development and localized computer services. Often it makes much more financial sense to adopt existing software and services and adapt them to the organization’s needs.
In these pages I emphasize the value of innovation and the power of Design Thinking to propel innovation. It can come as a disappointment then, to be charged with rolling out something you don’t actually design. Does this mean there’s no innovation to the task? Can Design Thinking still play a role?
It’s rare that only one offering is available for a given variety of cloud service. For every Salesforce there is a Microsoft Dynamics, for every Google Drive there is a DropBox, etc.
Design Thinking has a strong contribution to make during the selection phase. Design Thinking encourages listening to and observing the user community to develop a deep empathy for their needs.
Only by investing this time and effort can the offerings be compared effectively to user requirements. Too often user requirements get boiled down to a series of checkboxes for the vendor to tick. This can be avoided by preparing personas and user journeys to communicate with vendors.
Just as important, it lets those in charge of procurement know what components and feature sets to focus on during evaluation. Some offerings can be very broad suites and difficult to evaluate comprehensively. A little user-derived focus can help.
Assuming the cloud service vendor is willing to set up a prototype, this can be a great way to validate the user journeys and personas prepared, increasing the likelihood of selecting the best platform for the organization.
Configuration, or customization
Most cloud offerings have extensive configuration options that let the admins tweak the product for the users. Ideally all the work to make the product suit local needs can be done with configuration.
Going beyond this, into modifying the code itself, or writing additional programs that tap into the cloud service, can be risky. The cloud vendor will typically accept the obligation to write future versions with available configurations in previous versions in mind. At the very least, the vendor will prepare documentation or workarounds when new versions “break” configuration options used on the older version.
Local modifications or the product, or non-standard uses of the product will rarely survive a product update without expensive modification.
Whatever configuration or customization you elect to do should follow the Design Thinking principles of deep knowledge of what the user requires, implementing something quickly from which to garner feedback then observing how well the change meets those requirements.
There’s a tendency to throw canned training at staff who get access to a new cloud service. This risks squandering the user requirements that were carefully gathered earlier. Ideally a feedback loop will be made to connect the training given and the desired outcome. If user journeys were identified, take the time to document how they can be followed on the chosen system. Listen to and observe users as they follow these scripts to determine how training can be made more useful.
Compared to creating something new, implementing something off-the-shelf can seem like a slog with little opportunity to innovate. In fact there is a lot of Design Thinking work to be done, but it can be a challenge to convince all involved that the work needs to be done, especially when the whole premise behind buying something off-the-shelf was to save money and time.
The opportunity Design Thinking creates is to define success as something more than mere implementation (plugging in the VCR and walking away while it’s still flashing 12:00). With Design Thinking the goal is ensure the user’s needs are met. If the stakeholders can be shown the difference, then the costs of closer collaboration between the vendor, the technical team, the users and those responsible for training can be justified.
If your job was to develop the kind of systems that are now being purchased, this may be entering unfamiliar territory. Development is a special talent and demonstrating that talent is a natural source of pride.
Meeting with users to truly understand their needs, then working with them to ensure that the product is configured to meet those needs, and providing training or assistance to those users so they can derive that benefit – this encompasses a very different skill set. I think that this skill set will become increasingly valuable as the common challenge goes from developing something new and local to harnessing something already available on the cloud.
“The technology is the easy part. The hard part is figuring out the social and institutional structures around the technology.”
John Seely Brown
Evolution of thinking
At first blush it is possible to think that implementing an off-the-shelf solution will be drastically easier and cheaper (in terms of time devoted) than developing a new solution. Certainly there are savings to be had, but implementing a cloud solution, particularly if it is to have a big impact on the organization, is far from a no-brainer.
Most organizations recognize this, and adopt a project management mindset. Decide what must be done when, who will be involved etc, and drive the plan to completion.
A further refinement is to layer in Design Thinking. Work with the user community to develop a rigorous definition of success. Where possible add prototypes (whether wire frames, simulations, demonstrations) so that the solution that emerges matches that definition of success.
You may not be able to design the car but you still need to plan the route. Don’t fixate on the part you can’t alter. Make sure the part you are responsible for is focused on the needs of the end user. Use Design Thinking to know what the user needs and constantly refer back to those needs, comparing to what you have implemented, until those needs are met.