Workshop Process for Tablet app concept

Context:

While working as the design lead on an alpha product that was struggling to sell, I had begun to gather evidence that pointed to reasons why the product didn’t have market fit. For reasons outside of the scope of user experience, the product was not very useful in it’s current incarnation. See project here.

A UX researcher was later brought onto the project in hopes that he would be able to find the answer that would save the web app. He and I decided to do an exploratory exercise to find a tablet solution that would better fit the user context. The workshop for this exercise was outside of the Product Management roadmap and completely UX driven. The two of us took 2 days to collaborate while he lead us in his workshop process.

The outcome of the workshop, in his words, was that “instead of recommending redesigning small portions of [the application], or discovering the ‘one feature’ that was missing, we came up with two or three similar, related, but ultimately different products that that end user might use, but there wasn’t really a path to there from where the product currently was. Now, this didn’t kill the product, its sunset was already in the works. But it was another data point in support of the sunset. If the exercise had come up with “oh just this one thing that’s missing” it might have not been sunset, buuuuuut that’s not what happened.”

Vitorio’s Workshop Process:

Prior to the workshop Vitorio and I had some knowledge transfer around the domain and the user research (contextual inquiries, subject matter expert interviews, user tests) I had done in the previous months. We also did some archeological reviews of old documents and deliverables put together by the New Product Development team (NPD) in the early stages of the product and did some anecdotal research on the validation process for the product from both NPD and Marketing.

 Day 1: White boarding and brainstorming

 Task or process maps:

• Timeline of user workflow outside of the tool from beginning to end.
• Timeline of the existing user workflow in the current version of the tool (in this case it was very linear).
• A reverse-engineered solution by synthesizing the timelines into a more ideal workflow that allowed for asynchronous actions.

Counterparts:

For every action determined from the timeline, come up with lists of similar systems, workflows, or inputs or outputs, in other software or other industries. These are listed to explore the existing possibility space to see if known practices from other solutions or metaphors are conceptually compatible and can solve our problems here.

List specifics about each counterpart on how and why they could solve the problem/action.

Hard constraints:

Define a list of external design constraints in areas of the system that cannot be changed like: screen resolution, things that absolutely have to happen in a particular order, etc. These may be set by external parties or systems, or may be architectural decisions that make particular workflows unreasonable. They must be designed around.

[Define Metrics]:

Because this was a design exercise and we had a time constraint [working against a possible sunset of the product], we didn’t define success metrics. In Vitorio’s process that would have typically been done by using the following format:

“We believe [this statement is true] based on [the specific details about research we’ve done]. We will know we’re [right/wrong] when we see the following feedback from the [market/member C-suite exec/member user]: [qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].”

“We believe that [doing this/building this feature/creating this experience] for [these people/personas] will achieve [this outcome] based on [the specific details about the research we’ve done]. We will know this is true when we see [this market feedback, quantitative measure, or qualitative insight].”

Open questions:

Define list of questions that would need to be answered in order to have a final solution or hypothesis. These were questions put in a “parking lot” that couldn’t be answered by the two of us and required outside entities/stakeholders to answer.

Day 2: Conceptualize and sketch

Start sketching ideas and solutions for our concept based from the list of counterparts using the 6-8-5 method. 6-8 sketches in five minutes, show and tell, repeat, repeat, repeat until you have a solution or set of solutions everyone agrees on.

Vitorio and I iterated on our sketches until we had some solid solutions and hypotheses. We would have then presented our findings to key stakeholders and continued the process to build prototypes to test. Unfortunately the sunset of the product was underway and was finalized before we were able to save the day.

My next step would have been to refine the sketches in the form of wireframes and put together a prototype to test the PoC. The sunset of this product happened before I was able to work further on this and I was pulled onto other projects within the company.