Apr 2008
High-Fidelity Prototypes
04.29.08 Filed in: SVPG Blog
In several earlier articles I have talked about aspects of prototypes. I’ve talked about using them as the basis for your product spec, and how to use them to test out your ideas on target users, and why I prefer high-fidelity prototypes to their lower-fidelity cousins. In this article I’d like to highlight the top 10 major benefits of prototyping, and talk about some of the mechanics of building and using prototypes.
Benefits:
1) First and foremost, a high-fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.
2) Doing a high-fidelity prototype helps you - even forces you - to think through your product to a much greater degree than paper specs.
3) A high-fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.
4) A high-fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.
5) A high-fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product’s intended functionality and
design to be used as a reference basis for implementation and test.
6) A high-fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.
7) A high-fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.
8) If you do a high-fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost
in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.
9) If you do a high-fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.
10) A high-fidelity prototype helps keep the focus of the team on the user experience.
Notes:
- Prototyping tools have improved dramatically over the past several years. Whether you’re building a web-based application or installed client software, there are several excellent tools. In the web space, in addition to the many good web development tool suites such as DreamWeaver, there are now at least two products that specialize in the prototyping/visualization space: Axure (www.axure.com) and iRise (www.irise.com). The key is that you use something that lets you very quickly and easily create a realistic user experience.
- Because the prototype is just representing the user experience, and not the often much more difficult to write software running on the back-end, and
because the prototype is not meant to be production quality software (reliable, maintainable, scalable, fault-tolerant), you can usually use a much less skilled resource to create the prototype. The key is that the prototyper must be very comfortable throwing away the work of the past few hours to try a new approach.
- Once the team moves from product discovery into implementation, the prototype should be version controlled and placed under change control. Any
user visible changes to the product definition need to be approved by the product manager and engineering, and reflected in the prototype. The prototype serves as the key reference and master. It is the one artifact that the product manager, designers, engineers and QA use to reflect decisions made.
- It is perfectly fine for the prototype to use simulated data. The data should be realistic and plausible but does not have to be accurate. Generally, the prototype doesn’t access any other database or remote service.
For product teams using Agile methods such as Scrum:
Some Agile practitioners argue that the team should just consider the early sprints as the working prototype. And in fact, for custom software efforts
where there really isn’t true product management and rarely user experience design, this is the essentially the best you can do. However, for product
software organizations, you can and must do better than this, for three reasons:
First, a sprint is typically far too long to wait to try out an idea—an idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in days rather than wait months for one or more sprint cycles.
Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing—building production software.
Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach.
If you haven’t yet tried creating a high-fidelity prototype as the vehicle for discovering a product that is valuable, usable and feasible, I hope you’ll give it a try. It has never been easier to do so, and I find it one of the most powerful techniques for coming up with winning products.
Email to a friend
Sign up for the free newsletter here.
Benefits:
1) First and foremost, a high-fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.
2) Doing a high-fidelity prototype helps you - even forces you - to think through your product to a much greater degree than paper specs.
3) A high-fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.
4) A high-fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.
5) A high-fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product’s intended functionality and
design to be used as a reference basis for implementation and test.
6) A high-fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.
7) A high-fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.
8) If you do a high-fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost
in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.
9) If you do a high-fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.
10) A high-fidelity prototype helps keep the focus of the team on the user experience.
Notes:
- Prototyping tools have improved dramatically over the past several years. Whether you’re building a web-based application or installed client software, there are several excellent tools. In the web space, in addition to the many good web development tool suites such as DreamWeaver, there are now at least two products that specialize in the prototyping/visualization space: Axure (www.axure.com) and iRise (www.irise.com). The key is that you use something that lets you very quickly and easily create a realistic user experience.
- Because the prototype is just representing the user experience, and not the often much more difficult to write software running on the back-end, and
because the prototype is not meant to be production quality software (reliable, maintainable, scalable, fault-tolerant), you can usually use a much less skilled resource to create the prototype. The key is that the prototyper must be very comfortable throwing away the work of the past few hours to try a new approach.
- Once the team moves from product discovery into implementation, the prototype should be version controlled and placed under change control. Any
user visible changes to the product definition need to be approved by the product manager and engineering, and reflected in the prototype. The prototype serves as the key reference and master. It is the one artifact that the product manager, designers, engineers and QA use to reflect decisions made.
- It is perfectly fine for the prototype to use simulated data. The data should be realistic and plausible but does not have to be accurate. Generally, the prototype doesn’t access any other database or remote service.
For product teams using Agile methods such as Scrum:
Some Agile practitioners argue that the team should just consider the early sprints as the working prototype. And in fact, for custom software efforts
where there really isn’t true product management and rarely user experience design, this is the essentially the best you can do. However, for product
software organizations, you can and must do better than this, for three reasons:
First, a sprint is typically far too long to wait to try out an idea—an idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in days rather than wait months for one or more sprint cycles.
Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing—building production software.
Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach.
If you haven’t yet tried creating a high-fidelity prototype as the vehicle for discovering a product that is valuable, usable and feasible, I hope you’ll give it a try. It has never been easier to do so, and I find it one of the most powerful techniques for coming up with winning products.
Email to a friend
Sign up for the free newsletter here.
Product Organizational Structure
04.16.08 Filed in: SVPG Blog
In earlier articles I have discussed the key roles in the product organization – product managers, project managers, interaction designers, visual designers, usability engineers, prototypers, engineers, architects, QA and product marketing – and I’ve also discussed the ratios between the roles, but many organizations also struggle with the organizational structure that contains these people.
While I have seen - and continue to see - many different permutations out there, I do think that a standard organizational structure for product organizations has emerged over the past several years, and that there are good reasons for this structure.
I will admit that I do not feel nearly as strongly about the organizational structure as I do about the roles and responsibilities. I believe that if you have the right role definitions, and reasonable and well-intentioned management, you can usually make most organizational structures work, and I have no real problem with designing an organization around the strengths of the individual leaders rather than following a template from successful product organizations.
That said, we all know that organizational structure really does impact behavior, so all things considered equal, I argue that evolving towards the structure I describe below will improve the effectiveness of your overall product organization, sometimes in very profound ways.
Please note that I am only talking here about the product organization and not the other major areas of your company including sales, customer service, finance, business development and IT (as distinct from product development).
I argue that every CEO/COO or division GM needs three clear and distinct voices on his staff: Marketing, Product Management and Design, and Product
Development. As such, the most important aspect to the organizational design is that these three be top level, and one should not be buried within another.
So, reporting to the CEO/COO of a small or medium sized company, or each business unit GM of a large company:
- Marketing contains functions including corporate marketing, marketing communications, field marketing, and product marketing.
- Product Management and Design contains product management, user experience design (interaction design/information architecture, visual design,
prototyping, user research/usability engineering), and if applicable, subject matter experts.
- Product Development contains architecture, engineering, QA, release management, site operations (for SaaS companies), and project management
(PMO).
Notes:
- Notice that IT (the technical team that supports employees) is intentionally distinct from the product development organization. This is the topic of a future article, but for now let me say that the demands on these two groups are inherently different, and that it’s important to treat each appropriately. In terms of titles, normally the CIO runs the IT organization, and the CTO/VP Product Development/VP Engineering runs the product development organization.
- In some companies, the PMO is a top-level report and this is fine. But most often it’s part of the product development organization because the
vast majority of the resources the project managers deal with are part of that organization, and this allows the head of product development to be fully empowered and accountable for product execution and delivery. In any case, it’s important that the projects managers report into the PMO.
- It is a problem if User Experience Design is buried either in marketing or product development. It is critical that the user experience team,
especially the interaction designers, be very closely tied to the product managers. Keeping product managers as close as possible to the UED team is the reason for the trend towards combining product management and design into one organization (although each should have its own leader – the
director of product management is responsible for product strategy, and the director of user experience is responsible for the site/software overall information architecture and style.
- Marketing typically also has some number of graphic designers that support marketing programs and advertising. This need might be served out of the visual design team in the user experience org, but I prefer if they are a part of the marketing organization. A strong user experience requires
constant attention not just to the interaction design, but also to the visual design of the application, and this group should be managed by someone who understands what it means to support a product team. If there is a single Creative Director who understands both visual design for product, and visual design for marketing, the company is in great shape because one visual design group can serve both needs, and the overall expression of the brand will be very consistent. But if the head of the visual design team is under marketing, and isn't understanding the needs of the product, you will need to correct this situation as soon as possible.
- User research is sometimes separate from usability engineering, which is fine. But do not confuse user research and usability research. User research is background data on the demographics of the customers, or analytics of the customer’s behavior or buying patterns. It is not unusual to find user research as part of the marketing organization, which works so long as the product managers and interaction designers have ready access and a good working relationship with the user researchers. Usability research, by contrast, is specific research on personas, prototypes, or users' ability to easily navigate the product. These researchers' work feeds directly back to the interaction designers, visual designers, and product manager, and it is critical that they be an integral part of the user experience design team, so that their efforts can be collaborative and their research windows scheduled and closely managed to get feedback quickly during product discovery.
- Sometimes product marketing is part of the product management organization. This is not a big problem, and there are some advantages to that, but I prefer when it’s part of marketing as this helps to reinforce role definition and make sure there’s no confusion between product management and product marketing. To be clear though, even if product management and product marketing are part of the same organization, the roles should not be combined.
- Startups are a bit of a special case in that they are typically small enough that the organizational structure is minor compared to the personalities and individual skill sets involved. But remember that if things do go well, you’ll grow fast, and you’ll want to put an effective organization in place sooner rather than later.
If your organization is not structured in this fashion, then if things are working great I would not suggest changing a thing. But if your team is struggling, and if it feels more painful than it should to get good products out the door, then consider evolving your organization more towards the model described here and see if that doesn’t improve the situation.
Special thanks to both Chuck Geiger and Kyrie Robinson for their contributions to this article.
Email to a friend
Sign up for the free newsletter here.
While I have seen - and continue to see - many different permutations out there, I do think that a standard organizational structure for product organizations has emerged over the past several years, and that there are good reasons for this structure.
I will admit that I do not feel nearly as strongly about the organizational structure as I do about the roles and responsibilities. I believe that if you have the right role definitions, and reasonable and well-intentioned management, you can usually make most organizational structures work, and I have no real problem with designing an organization around the strengths of the individual leaders rather than following a template from successful product organizations.
That said, we all know that organizational structure really does impact behavior, so all things considered equal, I argue that evolving towards the structure I describe below will improve the effectiveness of your overall product organization, sometimes in very profound ways.
Please note that I am only talking here about the product organization and not the other major areas of your company including sales, customer service, finance, business development and IT (as distinct from product development).
I argue that every CEO/COO or division GM needs three clear and distinct voices on his staff: Marketing, Product Management and Design, and Product
Development. As such, the most important aspect to the organizational design is that these three be top level, and one should not be buried within another.
So, reporting to the CEO/COO of a small or medium sized company, or each business unit GM of a large company:
- Marketing contains functions including corporate marketing, marketing communications, field marketing, and product marketing.
- Product Management and Design contains product management, user experience design (interaction design/information architecture, visual design,
prototyping, user research/usability engineering), and if applicable, subject matter experts.
- Product Development contains architecture, engineering, QA, release management, site operations (for SaaS companies), and project management
(PMO).
Notes:
- Notice that IT (the technical team that supports employees) is intentionally distinct from the product development organization. This is the topic of a future article, but for now let me say that the demands on these two groups are inherently different, and that it’s important to treat each appropriately. In terms of titles, normally the CIO runs the IT organization, and the CTO/VP Product Development/VP Engineering runs the product development organization.
- In some companies, the PMO is a top-level report and this is fine. But most often it’s part of the product development organization because the
vast majority of the resources the project managers deal with are part of that organization, and this allows the head of product development to be fully empowered and accountable for product execution and delivery. In any case, it’s important that the projects managers report into the PMO.
- It is a problem if User Experience Design is buried either in marketing or product development. It is critical that the user experience team,
especially the interaction designers, be very closely tied to the product managers. Keeping product managers as close as possible to the UED team is the reason for the trend towards combining product management and design into one organization (although each should have its own leader – the
director of product management is responsible for product strategy, and the director of user experience is responsible for the site/software overall information architecture and style.
- Marketing typically also has some number of graphic designers that support marketing programs and advertising. This need might be served out of the visual design team in the user experience org, but I prefer if they are a part of the marketing organization. A strong user experience requires
constant attention not just to the interaction design, but also to the visual design of the application, and this group should be managed by someone who understands what it means to support a product team. If there is a single Creative Director who understands both visual design for product, and visual design for marketing, the company is in great shape because one visual design group can serve both needs, and the overall expression of the brand will be very consistent. But if the head of the visual design team is under marketing, and isn't understanding the needs of the product, you will need to correct this situation as soon as possible.
- User research is sometimes separate from usability engineering, which is fine. But do not confuse user research and usability research. User research is background data on the demographics of the customers, or analytics of the customer’s behavior or buying patterns. It is not unusual to find user research as part of the marketing organization, which works so long as the product managers and interaction designers have ready access and a good working relationship with the user researchers. Usability research, by contrast, is specific research on personas, prototypes, or users' ability to easily navigate the product. These researchers' work feeds directly back to the interaction designers, visual designers, and product manager, and it is critical that they be an integral part of the user experience design team, so that their efforts can be collaborative and their research windows scheduled and closely managed to get feedback quickly during product discovery.
- Sometimes product marketing is part of the product management organization. This is not a big problem, and there are some advantages to that, but I prefer when it’s part of marketing as this helps to reinforce role definition and make sure there’s no confusion between product management and product marketing. To be clear though, even if product management and product marketing are part of the same organization, the roles should not be combined.
- Startups are a bit of a special case in that they are typically small enough that the organizational structure is minor compared to the personalities and individual skill sets involved. But remember that if things do go well, you’ll grow fast, and you’ll want to put an effective organization in place sooner rather than later.
If your organization is not structured in this fashion, then if things are working great I would not suggest changing a thing. But if your team is struggling, and if it feels more painful than it should to get good products out the door, then consider evolving your organization more towards the model described here and see if that doesn’t improve the situation.
Special thanks to both Chuck Geiger and Kyrie Robinson for their contributions to this article.
Email to a friend
Sign up for the free newsletter here.
Eating Dog Food?
04.09.08 Filed in: SVPG Blog
I’m not sure how many of you have heard the phrase, “we eat our own dog food,” but for several years at least, companies especially in Silicon Valley have used this phrase in order to impress their customers that their product is so good that they run their business on it and use it themselves. This was practically a mantra at Netscape, and I can’t count how many times I’ve said this myself.
Today, I’m embarrassed to have said something so meaningless. Of course we used our own products. It would have said much more about the state of our products if we couldn’t use them. And yes, of course you should use your own products, but you need to realize that it’s just another form of QA. Just as you wouldn’t brag that your software passes unit testing, you don’t need to brag that you can actually use it.
But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.
If we like it, and we can figure it out, then others will too. The problem is that this just isn’t true. Yes, there are some niche markets like developer tools where it is somewhat true, but even there it’s less true than you may think. There are several reasons for this.
First, realize that not only do you not have to pay for your own software, but in fact you are paid to use it, as employees. It would shock me if SAP doesn’t use their own software to run their business, but it means nothing to me that they do. Their employees essentially have a blank check to make it successful. But their customers don’t. Imagine the SAP employee struggling with the product, and getting to the point where he says to his manager he wants to switch to Workday. Do you think that’s likely to happen? Of course not. But do you think this could happen at their customer’s site. It can and is happening.
Realize that your company’s employees are much more vested in your product and company than your customers, and that means you’ll tolerate more, much more than your customers.
Second, if we have a problem or a question, we can just go ask the developers. Your customers can’t. They have to read manuals, attend training classes, sit on phone calls with customer service, or sift through forums with other customers struggling through their own issues. Frustrating and time-consuming, and detracting them from whatever their real job is.
Third, a great many of us in tech companies are early adopters by nature. I know I am, and I also know that this means that what motivates me is going to be very different than what motivates target customers. This is a big reason why I like personas as a tool for calling this out.
But the bottom line is that all this points to how absolutely critical it is to test your ideas and your product on real target users and customers. If you haven’t been surprised by how different a customer’s response to your product is, then you probably haven’t yet done this type of testing.
Remember also that when you do this testing, it’s not enough just to get your product to the point where the user can figure out how to use it. You also have to get the product to the point where the user chooses to use it.
Email to a friend
Sign up for the free newsletter here.
Today, I’m embarrassed to have said something so meaningless. Of course we used our own products. It would have said much more about the state of our products if we couldn’t use them. And yes, of course you should use your own products, but you need to realize that it’s just another form of QA. Just as you wouldn’t brag that your software passes unit testing, you don’t need to brag that you can actually use it.
But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.
If we like it, and we can figure it out, then others will too. The problem is that this just isn’t true. Yes, there are some niche markets like developer tools where it is somewhat true, but even there it’s less true than you may think. There are several reasons for this.
First, realize that not only do you not have to pay for your own software, but in fact you are paid to use it, as employees. It would shock me if SAP doesn’t use their own software to run their business, but it means nothing to me that they do. Their employees essentially have a blank check to make it successful. But their customers don’t. Imagine the SAP employee struggling with the product, and getting to the point where he says to his manager he wants to switch to Workday. Do you think that’s likely to happen? Of course not. But do you think this could happen at their customer’s site. It can and is happening.
Realize that your company’s employees are much more vested in your product and company than your customers, and that means you’ll tolerate more, much more than your customers.
Second, if we have a problem or a question, we can just go ask the developers. Your customers can’t. They have to read manuals, attend training classes, sit on phone calls with customer service, or sift through forums with other customers struggling through their own issues. Frustrating and time-consuming, and detracting them from whatever their real job is.
Third, a great many of us in tech companies are early adopters by nature. I know I am, and I also know that this means that what motivates me is going to be very different than what motivates target customers. This is a big reason why I like personas as a tool for calling this out.
But the bottom line is that all this points to how absolutely critical it is to test your ideas and your product on real target users and customers. If you haven’t been surprised by how different a customer’s response to your product is, then you probably haven’t yet done this type of testing.
Remember also that when you do this testing, it’s not enough just to get your product to the point where the user can figure out how to use it. You also have to get the product to the point where the user chooses to use it.
Email to a friend
Sign up for the free newsletter here.
