Love the problem, not the solution

Technology, business considerations and user needs all play a role in solution development

Weeknotes #9: July 20–24, 2020

A tweet about a Hololens Tiger Team kickoff meeting at Transport Canada, in which I can be seen in the list of participants (speaking at the moment the screen capture was taken)
  1. deliver a solution that’s substantially better than the incumbent, in order to any overcome barriers to trial and adoption (solution space)
A photo of Ash Maurya, with a quote “Life is too short to build something nobody wants”
  • seeing relevant information overlaid in the users’ environment
  • navigating content and capturing notes through a non-text-based interface (via gestures and dictation)

Don’t talk to me about ‘validation’

People who’ve worked with me in the past know that I hate the word “validate”. It’s very easy to delude yourself and find evidence that supports your position.

A Venn diagram of feasibility, viability and desirability. Next to it is a paragraph by Tim Brown about design thinking

Starting with user needs

So, let’s say we have conducted research and learned that inspectors struggle with taking notes in the field. Being able to dictate their notes rather than stop to type them could be beneficial. That can help us feel confident about the problem, but that’s not the same as believing this is the right way to address the problem.


Of course there are business considerations!

Did you cringe above when I mentioned using my personal device? If so, you may have been thinking about the business considerations. If we’re trying to deliver a solution for our employees to perform their job, we don’t want to just let them use their personal device! We have business requirements (in this case, security is paramount!) we need to consider.

Sr UX Specialist with Canada Revenue Agency, former web dev and product person. 🔎 Lifelong learner. Unapologetic introvert. Plant-powered marathoner. Cat mom.