At this point we've discussed some of the various overarching questions present in the design of any project. But as you'll immediately realize if you start trying to answer those questions in earnest, those overarching questions are quite broad. Therefore, if we're really going to do a reasonable job covering and dealing with them we need to break them down a little bit further.
Before we do that let's make a distinction between two kinds of question present in the design. I'll call them technical vs vision. The technical questions are all about how to get things done. Architecture and tools both fall into this category. Vision is all about the what, why, when, and where. Use cases, self sufficiency, overall problems, and so forth all fall into this one. In this post I'm going to dig deeper into the vision aspect, i.e. everything but the how.
Use Cases
Obviously the very first question you must go about answering is - what are the problems I'm trying to solve - for as I said in a prior post there's a lot to be said for solving problems rather than creating solutions. That being said this particular brand of question is really only answered when you understand how people are going to use your tools so for me everything starts with use cases.
Use cases are simply how people are going to be using the tools/technology that you build. For example if I were talking about building a new pizza oven I'd have to think about how people are going to assemble ingredients, put things in the oven, configure the oven, use it, and remove and enjoy the result. In other words the use cases are really user journeys. Because they are journeys we can use the same trick we used for product development as a whole and break the use cases into clearer elements by creating a lifecycle. These lifecycles will be composed of a series of stages and dependencies and for each of these we can ask the who, what, why, and when.
By building out a lifecycle for each use case (or user journey) and carefully thinking through each stage and dependency in those lifecycles, we will create a complete picture of the tool and its ecosystem. Each component becomes something to test and build and as we continue developing our product we can incrementally update the user lifecycles with any learnings we find along the way. Our progress in building the tools are then described by completing these lifecycles.
Returning to the question of what problems are we trying to solve, we can look back through our lifecycles and understand the various issues we are solving in each stage or across stages. By doing things this way we ensure we capture details about how things get used in addition to what people are going to be getting at the end of the day. For example instead of just stating that our problem is "making a good pizza", by building out a lifecycle we might realize we also have the problems of "doing it easily" and "doing it configurably".
So to summarize the first step to answering the vision questions is to create lifecycles for each use case; understand each stage/dependency in terms of who, what, why, and when; and then derive our overall problems from those lifecycles and stages. Keeping diagrams of these lifecycles is super useful for keeping track of the state of a project and incrementally adding in new learnings.
Teach a Person to Fish
So we've captured how people are going to use the tools. But you'll recall that in order to ensure those tools act as catalysts we require self sufficiency on the part of the user. What does this mean? It means your tool had better be extendable. Extensions are thus the other half of the vision questions.
We can start breaking up this large set of overarching questions by recognizing that there will be two kinds of technology that we're putting together - core technology and extensions. Core is going to be whatever's needed to allow for extensibility and extensions will be everything else. While this may seem like we're putting far too much into the extensions bucket remember that you'll want to start training users how to make extensions as quickly as possible so that their work can be catalyzed as quickly as possible. This is the only way we'll be able to find unknown unknowns in extendability with any expedience.
Second we must recognize that just noting what kinds of extensions we expect doesn't necessarily mean those extensions are accessible. In order to truly catalyze work we need to make sure our technology's "energy barrier" to extension is suitably low enough. Therefore we're going to have to develop extension helpers. This can be as simple as documentation or as complex as a web tool - it totally depends on your users.
Finally, people usually aren't going to teach themselves, so there needs to be a curriculum of sorts for teaching people how to make extensions and use the tools.
To summarize, we have four components we're building: core, extensions, helpers, and curriculum. Now while we obviously need to document each of these in order to keep track of them you may question whether we should really be building extensions. Isn't that what the users are supposed to do? Well, often times, your users will still be learning how to use the tools and won't be up to the task of building extensions right off the bat. Yet, there may be extensions required to keep the project meaningful and moving forwards. Therefore your extensions are going to split into support and user developed. Support extensions are the ones you are building to keep the project moving forwards. Of course eventually you'll want all the extensions to be user developed, but while the project is under active development you'll want to keep track of both and methodically wean off of support extensions.
The wonderful thing about breaking things up into these components is that we can answer and detail each of these pieces in turn and capture what needs to be accomplished separately for each. For example you can spend time just understanding what extensions need to be enabled, which need helpers, which are going to be support vs user developed and so on. Then, separately, you can think about what's going to be in your curriculum, where various users are in that curriculum, and how to move them forwards. And then you can turn to your core tech and work out designs and components for that separately. It just gives you a lot of small problems with clear bounds to solve instead of one overwhelming mass of vagueness.
Timelines
Alright, so at this point we've got a whole lot of smaller, well defined components to think through that are going to each give us a whole slew of tasks to chase after. How on earth do we organize all these tasks into something coherent? Well that's where the MLP plan comes in. By taking all of these little tasks, organizing them into MLPs, and then planning the succession of MLPs, we take our smorgasbord of deliverables and create a neat, well organized timeline. And with that done, everything but the how is handled.
Summary
So let's summarize all of that.
When dealing with our big overarching questions it's useful to divide the problem into technical questions and vision questions.
We can tackle the vision questions by considering use cases and extensions.
For use cases we can create use case lifecycles that break up into stages and dependencies. By subjecting each of those components to that questions of who, what, why, and where we can fill in the full set of lifecycles.
For extensions we can make a division into four categories of work: core, extensions, helpers, and curriculum. Extensions can be further divided into support and user developed.
For each of the components we've now identified, we can dig in and understand what each means, what we know, what we don't, and what needs to be done. This work will result in a large number of tasks requiring organization.
This organization can be accomplished by taking all of those tasks and questions, organizing them into useful MLPs, and then organizing those MLPs into a timeline.
And finally, by capturing all of this in diagrams and notes, it'll be easy to keep track of everything that's going on while also allowing for incremental updates to the whole picture as we learn new things.
So there you have it! One formula for dividing and conquering everything but the how.
Comments