How to solve complex design challenges…

Today I had one of those days where you just feel like the solution you’ve come up with is not quite right. The business rules are loosely defined and the solution just appears to be too complex and inflexible. So you think about it a little bit more and try some alternate solutions. Soon you realize that there is little precedent for the problem you are trying to solve and it is going to be a long day. If all goes well it could be a rewarding one, but you know you are going to be in for a lot of think think thinking.

The problem:
Design a complex process for which the business rules are still being written. All you’ve got is a loosely defined goal (e.g., “Build a system for managing alerts.”)… And it’s due tomorrow. You’ve got to strike a balance between, and simultaneously define,  two important elements — the problem and the solution.

The tools I’ve employed…

  1. Consider anything you know about the users: Even without meeting with them, you can usually determine some common attributes about the audience. Tech savvy? Environment? Frequency of use for this tool? etc… Those come in handy later.
  2. Examine the closest precedent: How has this been done in the past? Has it been attempted before by me or others? What were the strengths and weaknesses of those solutions? What did they enable users to do? what did they leave out?
  3. Step away from the computer: Going analog with a pad and paper allows my brain to spit out the ideas more quickly than any digital format. The fact that it locks me in a bit helps too. I can switch from conceptual to detailed without having to create symbols and instances of stuff.
  4. Take a stab at it: Just complete one pass at the functionality at a high-level and see how it feels. A smart person introduced me to the concept of making a decision and then seeing how I feel about the results. This can help you get past the unknowns and often reveal some of what not to do. This is your base solution.
  5. De-construct the stab: Try to de-construct the version you’ve created to understand what your own biases, assumptions and implied constraints are. This helps you know where you stand and later, what you are changing.

    The moment of truthiness
  6. Share and invite: Bring other people you know into the mix. Sharing the initial solution for an ill defined process will almost always garner different responses because everyone involved has their own view of what the constraints and assumptions are. You need a tough skin here at times. People can have pretty strong opinions of what the design should solve. It’s not personal. This will lead to an understanding of several ways to look at the problem.

    Now you are getting somewhere… Next up…
  7. Apply other’s perspectives rapidly: Now try to walk through how the different perspectives would change the solution you’ve created. Don’t focus on the design as much as the assumptions. Throw some constraints out there. Put a line in the sand and say “the most important thing to the user is to understand the impact on the frequency of his alerts while setting new ones” or “The user should be able to understand the relative weight for each of her alerts”.  These don’t have to be correct. They just have to be in the ballpark. they will help you solve real problems instead of just talking about features. There are many ways to fulfill the requirements mentioned. Be aware of what the solutions enable as well as what they restrict or are not enabling.Don’t be afraid to play the role of devil’s advocate, therapist (how does that solution make you feel?), ringleader, naive user, etc. Anything that can help you draw out what people are thinking about the problems to be solved.

    While you’re at it…
  8. Throw some wrenches in there: Try out the solution that a key stakeholder has mentioned that you don’t quite agree with based on your design philosophy or experience. You will either determine that it has legs, or debunk it and have some evidence and thinking behind the recommendation.

    Finally…
  9. Converge on some themes and summarize the travels: “It sounds like we are not trying to solve x, so these two solutions are not in the mix.” stuff like that. Also apply Occam’s Razor and determine what the simplest solution is.
  10. Pick one solution… Then sleep on it: Everyone should leave the room with one solution in mind as the ‘winner’. I guarantee it will not be the final winner. But by choosing one – it allows everyone to think more deeply than was possible in the meeting. This allows that solution to stand the morning test. When people are rested from the exhausting meeting and have a fresh perspective on things.Now you can…
  11. Refine and present to the powers that be: The next time you share a solution with an executive team on the project, you can rest assured that you have developed a solution that represents specific assumptions. Plus, you are able to communicate those assumptions as well as show your thinking when others are tossed your way. This does not mean you are done. It just means you have a better chance at having something stick long enough to concentrate on some of the finer points sooner.If things do change, at least you know you’ve likely been there before in your thinking.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s