What to do with a bullet-pointed list of features

October 14, 2014 Nina Mehta

Our client came in with a short bullet-pointed list of features they want for their new iPhone app. Part of their ask was for us to validate and build that list. This ask is a tricky situation when your client really wants features that don’t get validated. Here’s what we did:

  1. Scenarios: Write short scenarios for each bullet-pointed feature. While we waited for user sessions to get scheduled we did a few rounds of sketching and dot-voting around one of the simplest scenarios.
  2. Research: Run 4-5 exploratory + generative research sessions. These sessions were:
    • 15-20 minutes exploratory interview
    • 10 minutes generating a “dream” paper iPhone app in our topic space with markers and stickers
    • 15-20 minutes understanding their prototype
  3. Synthesis: After each session we extracted and affinity diagramed our findings on sticky notes. Each participant got a different color so we could look for diversity of color in our clusters to find the strongest user needs.

    Affinity Diagram

  4. User Needs: On a whiteboard I led a session where we pulled out the user needs from the board of post-its. They sounded something like this:
    • I need help understanding my current [client name] plan.
    • I want to feel understood and recognized by [client name].
    • I want to experiment with what my [client name] plan could be.
    • I want to feel informed before getting on the phone with [client].
  5. Needs Mapping: Okay here’s where it gets fun. We rewrote each of the clients original features from the bullet-pointed on sticky notes and added a few new ideas that came out of the research and stuck them on the board. Those stickies got letters.

    We talked through each feature idea and assigned numbers (user needs) to them. Then the client PM was asked to select three features/letters that were diverse in numbers. This ultimately would lead to three very different prototypes.

    Whiteboard_with_markers

  6. New Scenarios: We returned to our original document. At the top of the document we edited some old scenarios and wrote some new scenarios based on the winners from the exercise in step 5. Now that the client has heard their people talk about what they need and how they feel, it became a lot easier to prioritize features that meet their users’ needs.
  7. Then we sketched and wire framed ideas that were better informed. Each of the sketches were quite different which helped us get a broad understanding of which features resonated with their users.

    As we’re refining and testing our product each week with new users, we lower our risk and gain more insight to make less risky decisions. And the client is now getting something they want, that their users also want.

    2014-10-13 17.58.42

About the Author

Biography

Previous
The Future Architecture of a Data Lake: In-memory Data Exchange Platform Using Tachyon and Apache Spark
The Future Architecture of a Data Lake: In-memory Data Exchange Platform Using Tachyon and Apache Spark

Pivotal is revolutionizing the data lake with an architecture that builds upon disk-based storage with memo...

Next
Security Analytics in Action: Use Cases for Deep Monitoring of Privileged Users
Security Analytics in Action: Use Cases for Deep Monitoring of Privileged Users

Pivotal data science and security expert, Derek Lin, has considerable experience in the areas of big data, ...