4 Reasons Why You Need Design Thinking to Drive Successful DAM
I have been in DAM consulting for 10 years. I have built a career on enabling my clients to achieve their DAM goals by advising them on strategies to get the best possible outcome for their investment. Sometimes they find my advice excessive “a whole RFP to choose DAM*?”, confusing “why would I define metadata before I’ve chosen the system I’ll configure it in*”, or superfluous “these workshops seem like a lot of activity to get to a simple answer.” Well, I am here to tell you that there are many reasons for these methods, and multifarious good reasons to use the activities and tools of design thinking to help you get the answers you seek for your optimal DAM tool.
1. Design thinking puts the end users at the center of the process
While other methods of requirements gathering may involve your end users, bringing them into meetings and asking them a series of questions, design thinking puts them at the center of the process. It acknowledges that as a fundamental principle of software design, the end users are all that really matters in the final product. After all, we’ve all heard the stories of the DAM project that failed because the end users did not adopt the system.
2. Design thinking uncovers the unknown unknowns
While stakeholder interviews provide a lot of information – yielding answers to questions when they are known, design thinking helps to uncover the unknown unknowns. It helps to elicit those details that even your end users did not know would become an issue down the line. It does this by visually imagining scenarios, walking through use cases, describing current issues and opportunities for improvement, and rapidly (and cheaply) creating end-product prototypes to test against assumptions.
3. Design thinking workshops are fun!
Stakeholder interviews are boring for everyone. Depending on the knowledge and experience of the interviewer, they could also be repetitive, or miss the point. Sitting across the table from someone who is firing questions at you, especially when you have no experience with DAM, can be daunting. Design thinking workshops are interactive and they inspire participation. People become engaged in the process and they can experience their voices being heard as they watch their words be illustrated in front of them.
4. Design Thinking workshops create lasting, editable and modular artifacts of requirements
When teams build a DAM program, there is often little thought given to the documentation. Notes are taken during meetings. Monster spreadsheets are created. And then a tool is configured according to the needs of the day – and then it is changed as soon as those needs change, with no continued documentation. Design thinking workshops, by their nature, create artifacts that document requirements and can be easily updated to reflect changes to needs. In fact, those changes in needs can best be defined by additional design thinking workshops. And these artifacts, such as end user personas and user journey maps, are easily editable, traded in and out, and are highly visual for a quick reference to why decisions were made the way that they were.
I am delighted to announce that I will be giving a four-part online education series in June, in partnership with Henry Stewart DAM, on the use of design thinking for digital asset management. In this series I will introduce you to the principles of design thinking and how they are applied to software and web development to improve user experience. I will then introduce you to some common tools in the designer’s toolkit that you can use to gathering your business requirements, define user stories, capture your end users’ needs, define your metadata and more to help you select, configure (or develop), and launch the best possible DAM for your business needs.
Join me in June for this fun workshop that you bet will apply the principles of design thinking to keep you engaged. Learn more and register at the Henry Stewart website.
*To answer these other questions – an RFP allows – nay forces - you to define your full requirements before selecting a system, then you can choose to invite only those vendors that meet your minimum requirements to demonstrate to you. Then you can choose based on your needs – instead of trying to fit your needs into the constraints of a system chosen based on other reasons. This answers the second question as well, why define your metadata before you know what tool you’ll be using? Because instead of trying to retrofit your metadata needs into the constraints of a tool’s functionality, your best possible outcome will be to select the tool that supports your metadata needs.