John Ellison

Day 60: Writing Content For Training Project Playback

3 min read

On Day 60, I spent most of the day distilling the Problemscape and writing content for the upcoming training project playback on Day 63. James Box had kindly provided us with a series of questions that each concept should address during the playback, and I setup a template so we could structure our content accordingly.

Here were the questions James asked us to answer:

  • Who are we trying to help?
  • What problems are we trying to solve?
  • How could we respond to these problems (value propositions)?
  • Why are we the right people to pursue this?
  • What is the opportunity size? (Competitors, market size)
  • If we wanted to take this further, what would we do next?
  • Where might this lead us eventually? (What's the vision?)
  • Why should we do this?

This task was also a good opportunity for me to read through all the content that Andy P had written regarding the concepts he had been focusing on, and it allowed me to make another pass through our competitor research to validate assumptions we were making about competitor offerings.

Setting The Problem Stage

Last week I spent most of my time focusing on how to articulate the concepts in form of a value proposition or elevator pitch. Upon presenting the concepts in that manner, I received a lot of feedback about the value of setting an appropriate context for the problems we are proposing to solve.

This was great feedback and one that I sorely needed. In writing about the problems I was trying to solve, it seemed like everything became much more clear and made total sense.

Finding Inspiration

During my research, I had stashed a few TED talks in my Evernote notebook, and so I used this opportunity to read through the talks' transcriptions and extract relevant language. There was one talk in particular that seemed to be very helpful in framing the problem.

It is a talk by a guy named Sugata Mitra, called Build a School in the Cloud. I've embedded it here because I think it is an amazing video that deserves to be watched by anyone interested in the world of education.

Why Us?

One of the questions James rightly asked us to answer in our concept pitches was "Why Us?". Here's a snippet of what I wrote for one of our concepts:

Clearleft was founded by individuals who learn by doing; Clearleft was founded with a belief in sharing what you learn. The combination of experiential learning and knowledge sharing has positioned Clearleft as a pioneer within the industry time and time again.

In the first era, Clearleft emerged as a leader in accessibility and web standards. But then the mission of usability and user experience design took reigns.

On the precipice of a new era, Clearleft has an opportunity to pioneer unchartered territory once again.

What would happen if we applied the learning from our 10-year journey to the world of design education? What would happen if we migrated away from doing great things to teaching others how to do great things?

Over the past few weeks, we have asked ourselves these questions time and time again. Out of a human-centered design process came an answer that rang loud and clear and resonated deeply within in our bones: Chorus.


I think I should have explored these questions far earlier in the project process because I found them immensely helpful. Maybe the work I did to clarify the concepts in the form of a proposition paid off, but it was definitely difficult to find the right combination of phrasing, positioning and tone.


John Ellison

Day 59: Discovering The Problemscape

6 min read

When James, Andy P and I sat down to discuss on Day 58, I used a word that I've never used before: Problemscape.

James chuckled at the word and we both thought it sounded funny. I'm not sure what he thought at first impression, but seeing as I used the word as a natural expression of a concept I was trying to articulate, I thought it was interesting at least. I'm not the biggest fan of smashing two words together and making it a word, but this word held something that I chose to explore on Day 59.

After Andy P and I finished our conversation on the morning of Day 59, I was left feeling quite confused and unsettled. It wasn't as if loads of conflict arose throughout the conversation, it was simply that our attempt of creating shared understanding seemed to obfuscated the concepts that I felt were otherwise clear (and maybe flawed, but clear at least).

Going Back To 10,000 Feet

During the conversation, I told Andy that I thought we were running over paths we've tread before and I was concerned we'd lost direction. I asked him if he'd bare with me for a moment while I tried to illustrate an idea that I had while he was talking. I hope he'll accept my apologies as I admit that my eyes may have glazed over a bit while I conceived this.

introducing the problemscape with andy p

Assembling The Problemscape

I felt our conversation began within the domain of one specific concept but quickly traversed into the broader territory of the bigger problems that we were trying to solve in this project. I began scribbling words on sticky notes and assembling them as I spoke. I wasn't exactly sure what I was after but I knew I wanted to visually represent the problemscape and verify whether or not we were talking about the same thing.

I broke down the whole project as we knew it into different categories. Here were the categories as I saw them:


There were several different audiences we were targeting: From individuals to organizations—each with their own type and flavor.

problemscape audiences


We had a range of problems that we were looking to solve.

problemscape problems

Context of Offering

We had two different contexts for offering: Public and private.

problemscape offering contexts

How Value Is Delivered

We had different methods of delivering value:

  • Training (topical)
  • Mentoring / Coaching (application)
  • Project (doing it for you...)

problemscape value delivery method


We had different durations in which the value could be delivered:

  • ⅛ Day
  • ¼ Day
  • ½ Day
  • 1 Day
  • 12 Weeks (6 sprints)

problemscape value delivery durations


We had different methodologies which we could apply to the delivery of value:

  • Design Thinking
  • Agile
  • Lean

Frequency of Delivery

We had a range of frequences at which the value could be delivered:

  • Once
  • Monthly
  • Weekly
  • Daily (Full-Time Immersive)


We had a range of disciplines that allowed us to strategically and tactically define and solve problems (that is, how we approach delivering our value):

  • UX
  • UI
  • Front-End Development
  • Project Management

problemscape method frequency of delivery and disciplines

Modes of Engagement

We had different modes of engagement:

  • One-on-one
  • One-on-many
  • Many-on-many

Outcomes, Not Outputs

When I started exploring the outputs, I listed a range of items, but realized at the end that the output doesn't really matter for the context of this project. Whether the output is a website, a web app, a physical product, a startup, or a social enterprise, as long as the problem is being solved and the desired outcome is met, the output could be anything...

problemscape engagement outcome and output

Read this awesome article by Ben Sauer for more details on why I chose to frame it this way: Outcomes, not outputs.

What Are Proposed Solutions?

In looking at the Problemscape by myself, I realized that the proposed solutions (value propositions) are just different packages of the following elements:

  • Target Audience
  • Audience's Problems
  • Our approach to solving the problem
  • The focus of the value
  • The outcome

When I looked at the Problemscape on my desk, I realized that I could select the individual elements and piece them together into a package. That package would be the core elements of the value proposition. Additional language and framing was necessary of course, but the core elements were there.

I think this exercise allowed me to step outside of each individual problem-solution pairing and look at the broader landscape of the problems and solutions we were proposing. This enabled me to reflect on the project as a whole and make sure that we were solving the problems we set out to solve and that we were meeting the needs of the audiences we defined in our research. It allowed me to think through each of the individual personas that represented broader groups of people and walk through their problems from their perspective.

It gave me the confidence to know that nothing was being left out. I could now see all the individual packages (value propositions) and make sure that we had total coverage over the Problemscape. We had a bunch of packaged solutions and some of them overlapped, but I needed to see how they all fit into the bigger picture of the project that we first set out to explore.

The Purposes of Canvases In General

One thing I've discovered as I've attempted to use things like the Business Model Canvas, the Value Proposition Canvas and Andy T's Project Canvas, is that I like concept but I often find myself butting up against the structure of the canvas. I like to design the categories of the canvas as pertains to the project and its specific domain (DSL if you like). I think that calling this exercise a 'Problemscape' might be overly grandiose, but maybe not. Maybe the elements together are helpful in other contexts. I think that the idea of using a canvas to break a problem or project into smaller parts is the main concept. How you do it and what you call each section is dependent on the DSL of the project.

What Do You Think?

I think this exercise was very effective and am curious to hear other people's thoughts. Have you done anything like this before? Have you embarked on an exploratory project and found yourself struggling through the details of many different concepts? Have you battled against blurred boundaries within concept definition? How did you approach the problem?

I'd be curious to hear your thoughts and learn from your process.

Tagged: ,