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.
Three strategies to get to stick:
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.
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.
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.
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:
The shortcomings I see with ProtoShare center mostly around pricing.
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.
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…
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.
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.
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.
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!
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:
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?
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.
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.
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.
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…
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:
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.
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.
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:
The advantages of the one-wheel approach are:
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!
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:
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!