• #SXSWi — How to get users addicted to your content

    I love addiction; perhaps because I have a very addictive personality.  As such, I was drawn to the talk here at South by Southwest by @taraattrulia about engineering addiction.  She’s going pretty fast, so I will.

    • Starting out with the definition of addiction.  Addiction does not have to be negative.  You want people to have a positive association with the addictive experience; not something they are ashamed of.
    • Recommends the book Lovemarks by Kevin Roberts.
    • Need to get into the ‘core mix’ of sites for a customer.  The path: reach–> trial–> stick.  The big goal: get the STICK!

    Three strategies to get to stick:

    • Don’t just publish information; fuel people’s aspirations.  People crave change; they want to be better than they are today.
      • Real-time helps people get more drawn into an experience
    • Market your manifesto.  Focus on lifestyles and values; you’ll find people who are already in your orbit.
      • You can engage people who are not directly aligned with your business.  They may just believe in the same stuff.
      • Lululemon example: their manifesto is about life; not black yoga pants (their core market?)
      • Secret (brand of deodorant): manifesto about bullying.
    • Double-down on content experiences.  Create unique content experiences that draw people in.
      • Lululemon yoga mobs (not sure what the better name is for this.. but they have thousands of people getting together to do yoga in public places.)
      • UGC call to action.  Trunk Club and Kiwi Crate –> users are posting their own content to facebook.

    My reflections on the talk are as follows:  I think it was heartfelt and interesting, but I failed to see any real connections to addiction.  The talk description mentioned stuff like neuroscience; but I the content was not specific or in-depth enough to make me feel like I really learned something deep.  Cool pillars, though.

  • A followup on rapid prototyping

    In an earlier post, I offered some thoughts on rapid prototyping. I mentioned my preference for the “high-fidelity prototype”, which leaves very little room to the imagination and provides users and stakeholders with a realistic sense of the user experience of the product.

    I’ve been using a couple of different rapid prototyping tools and thought I’d offer some opinions on their limitations and what looks promising as I see it.

    Rapid prototyping tools

    I’ve been using Balsamiq and Axure a fair bit. I think they’re both pretty good tools, but the problem is prototyping and design are subsets of communication and these two tools don’t seem to get that.

    You don’t come up with a design in isolation, you need to validate it with users and other stakeholders. For the most part, these tools make it easy to put UIs together, but they have issues when it comes time to send out your work for feedback. The biggest problem I see with both is managing workflows in the review process.

    Because they’re desktop based, you need to make all supporting files accessible to your reviewers and provide instructions to them for getting the prototype to look and act like it’s supposed to.

    In reality, by the time someone gets to the review, you’ve already made changes. Every time you send out a new iteration, you need to include lots of attachments and send everything out all over again. Getting timely feedback can get so aggravating that you reach a point where you don’t want to bother doing it at all. Major pain.

    And then there’s ProtoShare

    I got to thinking, “There must be a better solution, even if I have to build it myself”. Then I discovered ProtoShare.

    There are several things I really like and admire about ProtoShare – both the company and the tool, including:

    • When you first go to ProtoShare’s website, they talk about design as a form of communication, which I agree with and relate to. They seem to “get it” in that regard.
    • With ProtoShare, I can prototype in a browser but can also link pages to one another. Even though they’re just sketches, at least I’m able to link to them. Axure can do this too, but it’s a desktop tool so everything has to be uploaded somewhere.
    • The killer functionality with ProtoShare is its one-click publishing capability. You can prototype your whole site and then publish it to a live link to be shared with others to get feedback.

    Another advantage ProtoShare has against Balsamiq is ProtoShare uses built in Javascripts. Every time I use a Flash or Flex app, it doesn’t feel like a web application because of the way it handles scrolling, right clicks, text highlighting, etc. It’s the “Adobe way” of doing things that, to me, is just plain annoying and doesn’t feel natural.

    A few shortcomings

    The shortcomings I see with ProtoShare center mostly around pricing.

    • First, it’s not really cheap. The Professional version is $49.99 per month. For that you get up to 3 users and 10GB of web storage. Additional users cost $25 each – every month.
    • If you want to get feedback from someone, that someone needs to be a ProtoShare user. I really don’t see asking my reviewers to become ProtoShare members.
    A step in the right direction

    While it’s not perfect, I see ProtoShare as taking rapid prototyping to the next level. It’s not just wireframing, it’s really a collaboration and communication tool. Because it’s built in JavaScript, it feels native and not clunky. All in all, I’m a pretty big fan.

  • Some thoughts on rapid prototyping

    So I have made my feelings regarding functional specs pretty clear already. It’s clear to me, and a lot of other folks, that prototyping can be a very powerful way to capture requirements. What I have been thinking more about lately is, “What is the best way to do that?”

    While there probably is no single right answer to that question, I have been learning a lot so far. Here’s where I’m at.


  • Filling in the gaps with experience design

    The design of experiences is sometimes a mystical field of work. There are so many acronyms for similar or overlapping types of work that may affect the user experience: IXD, UXD, IX, IA, IAD, UX, UXR, VD, etc.

    No matter what your title happens to be, you are likely to be spending a significant part of your day thinking about how to design experiences that make sense and make people happy.

    Recently, I came across a great post over at UIE that covers the difference between designing for experiences and designing for activities…


  • Your Culture Really is Your Brand

    I read an interesting article titled “Brand Is Culture, Culture Is Brand”, which examined the relationship between the Human Resources and Marketing departments in an organization.  The premise of the piece is that, in the new paradigm of business, these two functions are intrinsically interlinked. I agree with many of the author’s points, and this is a principle I’ve always tried to employ in the businesses of which I am lucky enough to be a part.

    Your service drives your customer experience

    It has been proven time and again that people prefer to do business with a company they are comfortable with and which provides excellent customer service. In fact, many individuals would prefer to again patronize a company that may have made a mistake, but was diligent and apologetic in correcting it, over a starchy outfit that gets it right every time. This is a testament that the human factor is just too powerful to ignore.

    It’s almost a throwback to the era of “mom and pop businesses”, in that customers are searching for that personal attention and warm feeling from the establishments they patronize. Even if you are a large or multinational company, it is possible to establish a great culture and brand that is reflected in your staff.  And yes, this matters if your business exists only online.

    HR drives your culture

    I feel that the HR function, which is the gatekeeper of an organization, has a direct impact on the culture of the company and the ensuing customer experience. The degree to which HR exhibits expertise and diligence in hiring and promoting energetic, talented, and customer focused people has a direct correlation on company growth and customer relations.

    The idea of close collaboration between the HR and Marketing functions makes good business sense for a number of reasons.  The employees of a company are the face of the organization. If you think that the company bigwigs and investors have the most influence on public opinion and customer perception, think again. A customer remembers the person they spoke to on the phone, the clerk at the counter, or the technician that came out for a repair.

    Culture drives your brand

    I especially love the example in the article of USAA-a huge insurance and financial services company, serving military families. They offer a great training program in which new employees read real deployment letters, communications from soldiers stationed abroad, and walk in cumbersome 65 pound backpacks to get a taste of what it is like to be a soldier. This understandably inspires empathy, which comes across in how employees relate to customers.

    I’ve always felt that it is critical to have the right people in the right positions, and then let them run with the ball. They are the ones that will build and maintain the company’s overall voice and culture. If you examine the Forbes list of the Top 100 Places to Work, the list is littered with companies that are known for their dedication to employees and the customer experience. Some of the most recognizable are Google, DreamWorks Animation Studios, and Whole Foods. These names are synonymous with a great customer experience.

    There are so many options for a customer to choose from that the deciding factor is often the customer experience. This, more than advertising and promotions is what solidifies your brand in the minds of the public. I think that it is a promising trend that businesses are recognizing the power of their front line employees in their overall branding strategy. The marriage of Human Resources and Marketing just may be a perfect match.

    I’ll be giving this topic a lot more thought in the months to come, and I’ll report back with how things go!

  • Throw out your product specs…

    I don’t like requirements documents. There, I said it.  I’ve been thinking about this latently for a number of months now, but all of this thinking really caught up with me this weekend.  We’ve been thinking a lot lately about evolving our product management practices and there are no shortage of opinions around the office and from experts in the community.  As such, I’ve tried to do a lot of listening, reading, learning, and reflecting over the last few weeks.  Here’s what I’ve come up with so far.

    There are many flavors of requirements out there.  Depending on the product management practices you use, you are likely to have some of the following: product requirements documents (PRDs), market requirement documents (MRDs), business requirements documents (BRDs), software requirements specifications (SRSs), and feature specifications (FSs).  For the sake of simplicity, I’ll just refer to all of them as PRDs or specs.

    There are a number of shortcoming with PRDs. I’ll take the time to just list a few here:

    • They take a long time to write.  Also, they aren’t super useful until you are done writing.  (Think of the value curve as a stair-step function)
    • They are not enjoyable, engaging, or interesting to read.  Ergo, they aren’t read often.
    • Similar to the above, but potentially worse: they are nearly impossible to ‘diff‘ in most typical formats.   Which, for a living document, is bad.
    • They give people a false sense of security.  You read through that fifty pages and you think, ‘wow, we got this thing completely specced out.’  Wrong.  See below.
    • They don’t cover the most important of the product: the user experience.

    Let’s talk about what a good spec should do

    To me, a good set of requirements is supposed to describe a product that we are reasonably confident will be successful in front of real users.  But why does it exist in the first place?  Well, it’s core purpose is to facilitate discussion and decision making around the product in question.  Typically, there are a lot of stakeholders (with a lot of different paradigms) around that table: QA, Engineering, Marketing, Merchandising, Operations, Executives, etc.  So a good spec is able to quickly communicate what this product does and how it will do it.  The goal of such a specification is to create more clarity than confusion.  It should be your single source of truth.  Finally, a sustainable spec is one that is built for change.  Your product will no doubt evolve and change as you gain more insight from users.

    Delivering on all the expectations of a good specification is much easier said than done.  There are a lot of things that a spec has to do, and it’s only really useful if you can create it in a reasonable amount of time.  Furthermore, in most typical formats, the spec ends up getting thrown in the trash after the product is launched.  So you really don’t want to invest that much time into it.

    Also, there is a timing issue here.  How can we have any degree of confidence that our product will be successful without actually having tested the product in front of real users?   If you look at most specification creation processes, you’ll find that people are writing tens or hundreds of pages well-before they’ve actually put anything in front of a user.  What’s worse is that they haven’t even begun to think about the interaction or visual design of the product yet.   That’s counterintuitive to me because it goes against the most important rule I have learned in my time managing products: The user experience is the most important part of any product. It’s not about ‘what it does.’  It’s about ‘how it does it.’

    Now don’t get me wrong.  Some really forward-thinking product teams actually pay close attention to interaction design and visual design in their PRDs.  Some of them actually sketch out ideas and test them in front of users while building their requirements documents, which is a huge win.  If you are in that select group of forward-thinkers, you are definitely a step ahead.  But, in this scenario, there is an obvious question that we are left with: if you are actually beginning the process of product discovery (and doing real user testing), why are you using a document as the format to store your findings and insights?

    The ‘aha’ moment: prototyping

    When we look at all of the things that a specification is supposed to do well, it becomes clear that building a good one is a really tall order.  But when we combine the goals of communicating the needs of the product with actually validating/discovering the solution, an answer emerges: a high-fidelity prototype!

    The beauty of a high-fidelity prototype is that it actually provides people with a realistic sense of the user experience of the product.  A good prototype describes the functionality of the application while leaving very little room for imagination.  High-fidelity, to me, means that the interface is clickable, but that the backend is not necessarily functional.  In most cases, it will be ‘stubbed’ or simulated.  While every single corner case need not be designed, the major use cases and features should be fleshed out.  After all, the idea is to capture the proposed user experience.

    Imagine the kind of robust dialogue that can be had around a high-fidelity prototype versus a 50-page spec.  All of a sudden, these disparate stakeholders with very different frames of mind, will all (literally) see the same thing.  They will not only have a sense of what the functional requirements are, but they will see the proposed information architecture, user flow, interaction, and visual design.   They can actually understand how this product will come together and will have a much more robust understanding of what it means to them.  Also, they’ll have a single source of truth.  No need to dig through several email chains to find the answer to the question about a certain use case.  Just click through the prototype to find your answer.

    If you think a high-fidelity prototype will help facilitate discussion and decision making around a product, just wait until you see what it does for your engineering team.  Beginning engineering without having fleshed out the user experience can be very costly.  Typical specs are so ambiguous that the really tricky product management decisions are faced only after the engineers have begun writing code.  Also, typical written specs leave so much open to interpretation that its very likely engineers will write code that doesn’t do precisely what you intended.  This usually creates time pressure for PMs and engineers.  The pressure generally causes them to make hasty decisions without user input and to re-write code without taking the time to be thoughtful.

    But a high-fidelity prototype changes a lot of that.  The experience has been thought through much more significantly by the time the engineers begin writing (back-end) code.  Furthermore, there are few (if any) better ways to communicate the needs to an engineer than to show them precisely how the application is supposed to behave.  They can actually foresee some of the challenges ahead and can be much more thoughtful about the architecture.  That’s not to mention that their velocity is likely to increase because they have more clarity on what they are building.

    Last, but certainly not least, is the effect on the user.  The great thing about using a high-fidelity prototype as your ‘source of truth’ is that you can actually put it in front of users to get feedback.  This enables you as a product team to ‘test early and often.’  And instead of taking all that extra time to ‘write up’ your learnings from user testing, you can just work with the interaction team to evolve the prototype.  Which means you can iteratively test it again and again until you’ve gotten the experience right.  You are able to test much more easily at this stage because the cost of change is so much lower than it will be further downstream.  Once you are ready to begin implementation on the prototype, no additional administrative work is needed (in the form of writing pages and pages).  Instead, you can just begin involving engineering in the discussions around the prototype and they can begin turning it into a real product.

    Give it a whirl

    If you’re a skeptic right now, that’s OK.  It’s likely that your existing process is painful enough that you’ll get open-minded about this sooner or later.   Next time you have the opportunity to create a product spec, you should consider working with your design team on creating a prototype instead of spending weeks or months writing a longer PRD.  Get that prototype in front of real users (and the rest of your product team and stakeholders) and use it as a catalyst for dialogue and decisions.  When it comes time to implement, bring your engineers into the conversation.  I think you’ll be pleasantly surprised at the result.

  • How to successfully integrate into a new company

    New team-members are not created equal

    I’ve had the opportunity to evaluate and hire around thirty very talented people in the last few months, and it has been a pretty eye-opening experience for a lot of reasons.  Perhaps the most interesting reason is the varying outcomes I have seen from all these new employees.  I have seen some new employees do a fantastic job of integrating themselves with the culture and the team, and I’ve seen others crash and burn.

    It got me to thinking, “what is it that makes certain new people successful in an organization and others not-so-successful?”  If there are certain attitudes and behaviors that drive good outcomes for a new team-member, I’d like to know what they are.  This is especially interesting because I find that some team members who I am excited about during hiring/evaluation process actually don’t do so well in their first 30-90 days.

    So, I’d like to better understand what works and what doesn’t.  That way, I can try to help coach new employees in that direction.   I’ll establish a working list here, and try to add to it as I learn more.

    Things you should do when you join a new organization

    • Respect how the organization got to where it is. The most successful employee don’t just walk in guns ‘ablazing.  Instead, they seek to understand how the organization got to where it is now, and what things have been successful or not-so-successful in the past.
    • Assume that past decisions were made for a good reason. I’ve seen a few new team-members actually disclaim that they ‘they are not here to question past decisions.’  They assume that people made the best decisions they could with the information they had.  This is a great way to start off on the right foot with a new team.  Of course, no organization is perfect, and all of them have skeletons in the closet.  But you are better served focusing on the future rather than the past.
    • Recognize that some of your great new ideas were probably discussed before. This is one of the most common mis-steps.  I see a lot of new people come to the table with ‘great new ideas’ that they assume no one has thought of before.  It’s great to be forward-thinking and to have new ideas, but it makes a lot more sense to first ask if folks have talked about things like this in the past, and what has been done until now.  (Most companies are not short on ideas… they are short on execution!)  If you don’t ask these questions, you look ignorant about the history of the organization and you look like you are trying to take the credit for ideas that people have already had for a long time.
    • Get to know people both personally and professionally. You cannot underestimate the importance of close personal connections in the workplace.  You don’t have to be best friends with your co-workers, but you should make an effort to get to know them and what motivates them.  The more comfortable people are with you, the more likely they are to come to you when they need something.
    • Ask questions… rather than giving answers. This is more of a meta-point that covers a lot of the other points above.  But it’s a great rule to live by.  If you find yourself providing more answers than questions in your first month, you are almost certainly doing something wrong.  You have to seek to understand before you seek to be understood.  (Take it from Covey!)
    • Seek out a mentor. There is almost certainly someone in the organization who knows more about the brand and the culture than you do.  Don’t be afraid to ask for help.  It’s not a sign of weakness, it’s a strength.

    This topic is not only timely for me, I think its hugely important in any rapidly growing organization.  There are lots of new faces and there is a lot of uncertainty.  What I have found is that some of the brightest people have the least organizational savvy.  So if you think this advice doesn’t apply to you because you ‘smarter than that,’ I encourage you to think again.  No matter how smart you are, you are not going to be effective in an organization where you haven’t built trust and don’t have the ability to gain buy-in.

    Joining a new organization can be harder than most people think.  Hopefully some of this advice helps people on their way…

  • Design thinking

    Designers don’t just ‘throw sparkles.’

    In the last post, we explored some of the differences between entrepreneurship today and ten or so years ago.  As I think about how creativity and innovation seem underrated, it gets me to thinking about the way that design is perceived in most organizations.
    When most people think or talk about design, it seems that they think about the classic definition that was popular many years ago.  To me, this definition is more or less “the art of making things look pretty.”  Or, as one of my favorite colleagues likes to say, “throwing sparkles at things.”
    But, to me, design is no longer simply the art of making something look ‘pretty’ or ‘sparkly.’  It’s less about putting a good looking wrapper around something that already exists, and more about coming up with interfaces or products that solve new problems in a meaningful way.  In other words, I don’t think of designers as people who simply come into the picture after all of the innovation is done.  I think that designers are the very people who drive the innovation in the first place.

    What is design thinking?

    One of the exciting new topics I have begun to read about is called ‘design thinking.’  I recently read an article in the June 2008 issue of the Harvard Business Review by the CEO and President of Ideo, Tim Brown. It was a fantastic outline of what design thinking is all about.  Here’s what I learned:
    You don’t have to be a designer to employ design thinking.  It’s just a structured approach to creating innovative and effective solutions to problems.  In this way, anyone can be a designer of new products or services.

    The Characteristics of a Design thinker

    Most effective design thinkers who have pioneered the creation of new products and services seem to exhibit some core characteristics:
    • Empathy: This is about taking a people-first approach.  You must work to put yourself in the shoes of others.  You have to think through solutions from multiple perspectives, and be willing to observe the world in minute detail.
    • Integrative thinking: This is about avoiding the very typical “either or” thinking of tradeoffs in design problems.  You want to embrace the contradictory aspects of a challenging problem.  The secret is to try to eliminate tradeoffs by achieving a solution that tackles “both A and B” as opposed to “either A or B.”
    • Optimism: Most worthy design problems are really hard to solve.  You have to assume that a ‘best approach’ really does exist, no matter how hard it might be to find.
    • Experimentalism: You have to be willing to explore constraints creatively, and to push boundaries as necessary.  Instead of just trying to speculate your way into the best answer, you’ll want to try multiple options (perhaps all at once) to figure out what really works.
    • Collaboration: Most great products are not the brainchild of a lone creative genius.  Instead, they are born through the clash of perspectives of people who come from different disciplines.  You have to be willing to seek out and embrace that kind of conflict.

    Why should you care about design thinking?

    Both my intuition and my experience seem to confirm that there really is something to this whole notion of ‘design thinking.’  It’s this kind of thinking that yields great outcomes.  Anyone who wants to create really great solutions to problems should try to embrace it.  Most importantly, you shouldn’t think of this kind of disciplined ‘innovation-focused’ thinking as something relegated only to designers in the back room.  It’s something that should be embraced from the CEO all the way down to the individual contributors who are building a product.
  • Agile Design: continued thinking

    In my last post, we just began exploring the idea of agile design.  The quick conclusion was that there are significant similiarties between design and development as creative processes.  Agile thinking can be effectively applied to both.  The big question is about specific implementation.  How would it work?

    There are two ways that I have seen agility applied to design.  For lack of better terminilogy, I’ll call them the:

    • two-wheel approach
    • one-wheel approach

    Let’s start with a quick explanation of what each wheel means.  The two-wheel approach treats design and engineering as two separate teams (or even two separate organizations).  In the two wheel approach, the both teams are working iteratively to push ‘shippable deliverables.’  For designers, it would be shippable designs.  And for coders, it would be shippable code.

    The natural progression of work tends to be that the design is done before the development.  As such, the the design iterations generally drive the development iterations.  Once a design product has been marked as solid enough for implementation, it is ‘completed’ in the agile design cycle and it marks the beginning of an agile development cycle.  The lengths of the iterations don’t have to be the same across design and development.  In fact, I’ve seen shorter design iteration length have a better chance of success.

    This is one way agile design and development can be done.

    The one-wheel approach is primarily different in that it treats design and development as one ‘product development team.’  This is a cross-functional agile approach for which there is very little precedent.  In this approach, the team is all pushing towards one shippable deliverable together, and each person is doing their part side-by-side with folks of other disciplines.

    In the one-wheel approach, the work is not as cleanly sequential.  What ends up happening is that some work is sequential, other work is parallel, and a lot of work ends up happening in mini-iterations within the iteration.  For example, a designer may produce a mock and pass it to a developer, but can be involved in ensuring that it is implemented in a pixel perfect way by the developer on the team.  As the developer has real-time feedback, the designer could very quickly re-mock and pass the mock over again.  As the UI of the app increases in fidelity, the designer can start producing unforeseen assets like icons and other images that are implemented downstream.

    Another way to accomplish agile design and development.

    Of course, the million-dollar question is: which approach is better?  The honest truth is that I don’t know yet.  I have used both and have seen pros and cons to each.

    The advantages of the two-wheel approach are:

    • Much easier to do when teams are distributed.  (Even moreso if they are distributed by function.)
    • Enables cleaner divides in the organizational structure.  This is particularly useful if your organization is already entrenched this way.
    • Easier to implement from a complexity and organizational change standpoint.
    • Potentially more efficient in terms of people working on the thing they are skilled at all the time.  (Little to no downtime.. and designers are always designing and coders are always coding.)

    The advantages of the one-wheel approach are:

    • You get more happiness and buy-in because everyone is involved in the final implementation decision.
    • When velocity really matters (you are under the gun), the micro-feedback cycles of a cross-functional team are significantly faster.
    • Potentially better outcomes from having diverse viewpoints at the table.
    • Potentially more scalable.  Having many cross-functional teams scales more cleanly than bigger and bigger functional teams.

    What I am trying to figure out now is: are these approaches more or less appropriate for different circumstances or phases of growth?   I, unfortunately, don’t know the answer yet.  Of course, if you are not in a startup or not in a position to mold the structure of your organization, then the constraint of organizational structure can drive your decision.  (Most of the time, that will drive you to the two -wheel approach.)

    The one-wheel approach has some potentially large benefits (like better product outcomes and more buy-in!), but it takes a lot more organizational buy-in.  Cross-functional teaming can be very complex to implement, particularly in organizations where different leaders of different organizations have strong visions for ‘how things should be done’ in their world.

    I’ll try to report back after I know more!

  • Agile Design: Myth or Reality?

    So, I have been fortunate enough to be part of a lot of conversations with a lot of smart people recently.  A good number of them have been centered around one topic: agile design.  For me, it’s sort of funny that this topic has come more and more into the spotlight over the last year.  The first time I started talking about ‘Agile Design’ was in 2008, when ModCloth was just starting to build out it’s design and development competencies.  Back then, I think people mostly thought I was crazy.  The feedback was plain and simple: “agile doesn’t make any sense in design.  Developers don’t understand our world.  Our process has to be ‘creative.'”

    Today, I think folks are slowly but surely coming around.  If I had to guess why, I would say that it has to do with the environmental factors mostly.  Agile methodologies have grown in popularity, considerably so in the world of software development.  A lot of folks have been evangelizing their specific brand of agile over the years, and I feel like it’s really hitting a tipping point.  (Or more likely, it has already hit the tipping point.)   So people are realizing that agile is really here to stay, and that means that it’s really hard to ignore in the design world.  The most compelling reason, of course, is that one of the core principles of agility is empowering the team.  So if the software developers are empowered to start envisioning the software — when do the designers get involved?  Well, in some companies I know, the designers are mostly charged with making stuff ‘look pretty.’  How fulfilling is that?

    Ok, so agile is here to stay.  And it creates a weird situation for designers (and others) in organizations where only the software developers are practicing agile methodologies.  And now days, people are starting to throw around this phrase ‘agile design,’ even though what it means is is not clear to anyone.   So, let’s figure it out:

    The core principles of agility are simple, in my words:

    • Chaos: Agility is all about unpredictable processes.  The primary goal is to be able to respond to change as opposed to following a plan explicitly.
    • Bravery: Unless you are brave enough to make mistakes or get feedback before things are ‘perfect’ in your mind, you are always going to lean towards waterfall.
    • Get real: The idea is to build stuff instead of creating comprehensive documentation that tells you what to built.
    • People over process: It’s about getting smart people together and figuring out the solutions as opposed to being too prescriptive about following rigid processes.
    • Collaboration:  If everyone is on the same team, everything gets done faster.
    • Iteration: Don’t try to build towards a ‘grand unveiling’ — that never works.  Instead, build iteratively and get feedback along the way.

    Because I can’t live with myself without sketching out a quick visual of how these principals drive one another:

    So, before we do anything else, let’s ask ourselves this: do the principles above apply to design?  My gut tells me the answer is yes.  Chaos is a reality of nearly any organization.  You cannot clearly predict the future, so you have to be ready for change, and you have to be ready for your vision to evolve.   And the same bravery that would enable a developer to show someone their code or their half-complete feature is the very same bravery needed by a designer to show someone a design before they think it’s 100% ready, no?   And the principles of iterative work and collaboration also still apply to design, no?

    So can you engage in agile design?  The answer appears to be yes.  Is it exactly the same as agile software development?  Of course not.  It’s safe to say that both software development and design are creative processes.  But they are not exactly the same in terms of how they are accomplished (or how long they take to get accomplished.)

    But there is more to this topic than meets the eye.  If your organization is going to buy-into the idea of agile in the realms of both design and development, how are you going to enable both of them to get together?  That seems to be the core question.  I’ll followup with some thoughts on that soon!