The Lean Launch: Design (Phase Two of Five)

Leave a reply
This early sketch of the Bigshot camera by Shr...

This early sketch of the Bigshot camera by Shree K. Nayar shows some of the form factors that were considered during its initial design phase. (Photo credit: Wikipedia)

Continuing on from our process in the define phase, we now have a document that lists our thesis, users, their goals, objects, relationships, attributes, and processes. Now we’re ready to start getting down to realizing our plan on paper. But don’t jump to Photoshop just yet! As we’ve gone with a top-down approach, we’ll continue that in the design phase as well.

Design, Step 1: Create a series of screen requirements.

Now it’s time to translate our processes into a conceptual set of screens. What steps in the processes logically combine together? What states do each element appear (e.g. initial, focused, accepted, error)? You may need to conduct some user research, such as card sorting or participatory design, to correctly organize these elements into screens. Don’t worry about layout or visuals just yet, first focus on listing out what needs to be on each screen, and how the screens connect to each other.

Design, Step 2: Draw up wireframes for each screen.

Now that you have your screen requirements, its time to figure out how to lay them out. There’s a million wireframing tools out there; I’m still an advocate for pen and paper wireframing.  Don’t think about graphical elements yet, just focus on laying out each screen and making them work together.

Pay particular attention here to keeping similar functions on the same part of the page throughout. Also emphasize the hierarchy of elements; which elements are the most important?

Normally, it’s a good idea to come up with several wireframes for each screen, and to look at them collectively to find patterns that work well together. You may wish to conduct usability testing on your wireframes, or surveying to decide user priorities.

Design, Step 3: Design a style guide that defines the look and function of elements.

Now that we know what elements are going to appear throughout our project, and we have an idea of how things will be represented, we can come up with a style guide. You’ll want to develop a consistent look and feel that covers most of the element you need. If you aren’t familiar with style guides for application projects, you may wish to look at the Twitter Bootstrap or Github CSS Style Guide as well-developed examples.

Your style guide should end up in the medium of the project, be it HTML and CSS or XCode ready so that it is put into practice. Pay particular attention to typography, grids, and metrics, as these will define most of your other elements. I highly recommend conducting user research in this stage as well to find out how your users identify themselves, such as intellectual, funny, detail-oriented, opinionated, etc., and let the visuals reflect your users.

Design, Step 4: Compose your screens.

In the last stage of the design phase, you want to put the wireframes and the style guide together to make compositions of each screen. You can develop these compositions in any medium you choose, but I’d recommend in the end having them ready to be implemented in code as with the style guide. In some cases, once you have the style guide and wireframes, that may be enough information by itself to generate your pages: YMMV. In more complex cases, a composition will be necessary.

If you have more than one person on your team, its easy to distribute the project across multiple people and in an iterative fashion. You don’t have to do the steps in precise, waterfall, order. You’ll need to start the planning phase first, but once you define the user goals you can start design and development simultaneously and iteratively. After we go through the five phases, we’ll write another post about how this process can be divvied up and broken into smaller pieces.

Review

  • You’ll want to do most of the define phase before entering the design phase.
  • The four steps of the design phase are screen requirements, wireframes, style guide, and composition.
  • Use a top-down approach. It’s easier to make good decisions when you focus on one problem at a time.
  • Conduct user research as you design; research data will make your decision-making much easier and quicker.

Next week we’ll go into the development phase, and we’ll cover how our planning and design ties into the way we carry out our ideas.

Phases

  • Phase 1, Define: Thesis, Users, Goals, Objects, Relationships, Attributes, & Processes
  • Phase 2, Design: Requirements, Wireframes, Style guide, & Composition
  • Phase 3, Develop: Server, Models, Controllers, Views, Development, & Launch
  • Phase 4, Distribute: Branding, Account, Write, Business plan, Research, Legal, & Monetize
  • Phase 5, Iterate: Research, Design, Develop, Market, & Support

 

The Lean Launch: Define (Phase One of Five)

1 Reply
Ares I-X Upper Stage Pre-impact

Ares I-X Upper Stage Pre-impact (Photo credit: Wikipedia)

As mentioned last week, we’ll be working on describing the process we used to get a minimum viable product release of ConceptCodify out the door in less than one hundred hours of total time. For the first phase, we focused on planning and research. This process focuses on a top-down approach, and of course, is user centric throughout. We’ve started a few apps before and this process is the refinement of several launched MVPs.

Define, Step 1: State your thesis.

The very first thing you need to do once you have your thoughts together is come up with a thesis statement for your product. The easiest way to do this is to define the problem you are solving first, and then state how you are going to solve it. Don’t focus on getting all the features or details down yet, leave it to a sentence or two just to get started. But take the time to make this the most important sentence you’ll ever write.

Example: ConceptCodify is a card sorting application designed so everyone making websites and apps can conduct their own card sorts without expert research knowledge.

Start a document at this point. I love markdown for these types of documents, but any word processing environment will do.

Define, Step 2: List your types of users.

The next thing you need to do is list out the major types of users that will use your product. Some cases, there will only be one type of user, most of the time there is two. Sometimes there will be up to five types of users. More than that and you’ll probably go crazy. Don’t get caught up in the details yet, but come up with a good word for each type of user, such as researcher and participant, because you’ll be using them a ton.

Define, Step 3: Define the goal for each user type.

Just as you defined the goal for the overall project, take this time to list the problem and solution for each type of user. Refine it down into one sentence each. Once you have this, you’ll likely want to similarly define some of the expectations, resources, motivations, and attitudes for each user type. You may need to do a little user research at this phase to be able to articulate these aspects of your users. Qualitative surveys can help to illuminate these aspects quickly. You may even realize there are more types of users as well.

Define, Step 4: Define the objects in the process.

The next thing we need to define are the major conceptual objects the users will be interacting with as they try to accomplish their goals. For example, in ConceptCodify, the objects are studies, collectors, and participant responses. These are somewhat abstract objects. You’ll likely revisit and refine this step as you work through the next few steps, and that’s an important part of the planning process.

Define, Step 5: Define the relationships between users and objects.

Now that you have a list of users and objects, you’ll want to draw out a map of their major interactions. Don’t worry about every little detail, refine so that each user type has about 2-3 major interactions. I find it easiest to write each of the user types and objects in a circle, and draw lines between them.

relationship diagram

You’ll likely want to add each relationship in your document under each type of user and object.

Define, Step 6: Define the attributes of each user and object.

Now that we know what the major relationships are, we can now talk about what information we’ll need for each type of user and object. For example, users will typically have a user name, email address, and password. Researchers in ConceptCodify also have notifications settings, organization name, and logo. Go through each type of user and object and determine all the attributes you’ll need. Again, as you continue through your journey, you’ll come back and revisit and refine.

Define, Step 7: Define the major user processes.

Now that we have a basic understanding of who, what, and why, we need to define how. Don’t focus on visuals or layouts just yet. At this stage, revisit your user goals. Create a step-by-step process for how the user interacts with the objects and other users to achieve their goal. Describe what attributes of the objects and the users are impacted at each step. Continue to refine this step. You may need to revisit and refine earlier steps at this point. If you are also unclear as to your users’ expectations or resources, I highly suggest conducting some user research to clarify your users’ thoughts during these early planning stages. You may want to review our article on the cognitive conversion process at this stage.

If you already have a name in mind, now’s not a bad time to register your domain name and procure the user name on Facebook, Twitter, and any relevant social media sites.

Review

  • The seven steps of the of define phase are Thesis, Users, Goals (Personas), Objects, Relationships, Attributes, and Processes.
  • Don’t worry about visuals or implementation yet. Start from the largest ideas, the big picture, and break it down from there.
  • Conduct research where you are unsure. This is the time where research will have the most impact.
  • You don’t have to get it perfect. You’ll refine your definition as you work on your project.

Next week, we’ll start talking about the design phase. Stay tuned!

Phases

  • Phase 1, Define: Thesis, Users, Goals, Objects, Relationships, Attributes, & Processes
  • Phase 2, Design: Requirements, Wireframes, Style guide, & Composition
  • Phase 3, Develop: Server, Models, Controllers, Views, Development, & Launch
  • Phase 4, Distribute: Branding, Account, Write, Business plan, Research, Legal, & Monetize
  • Phase 5, Iterate: Research, Design, Develop, Market, & Support

Upcoming Post Series: Lean Launch

1 Reply
Garden flower

Garden flower (Photo credit: Wikipedia)

ConceptCodify was planned, designed, developed, and launched, all with under 100 hours of combined time. How was this possible? Many talk about minimum viable product; we actually did it and then some.

In our upcoming series, we’ll cover the process we used to get ConceptCodify to launch. There’s essentially five major stages to our launch strategy: define, design, develop, distribute, and iterate.

Overall, there’s about 24 total steps. That may sound like a ton, but most are fairly quick. Best of all, our plan keeps getting to launch user-focused and user-driven.

Stay tuned!

Why most organizations should keep their research lean and cheap

Leave a reply
my life's logos v.2

my life’s logos v.2 (Photo credit: captcreate)

Over the last few months we’ve mentioned tons of tools that are available for conducting user research. It’s easy to get lost in the number of options and making sure you find the right one. There’s a bigger picture to this concern, however.

As you start to conduct more research, you’ll find the need for one time use types of research, and sometimes you’ll find that your current tools don’t completely meet your needs. And that’s okay.

The truth is, and many companies don’t want to admit this, but most user research can be conducted for free without much of any tooling at all. Sometimes, it can be easier to build your own tools. Why is this relevant?

It’s relevant because as you start to scale your research, and you start to become habituated to it, as many of us do, we start to accumulate more and more tools. I have a few recommendations for when you get to this point.

  1. It’s fine to pay a monthly rate for your regularly used tooling, such as usability testing, surveying, and recruiting. Some of the more specialized techniques that are more case-by-case, such as card sorting, heuristic evaluation, and diary studies, you probably want something that’s per-use basis. Most of the monthly tools will let you cancel at any time. If you need to go this route, find a tool that doesn’t limit access to your data after you cancel the subscription.
  2. If you have more than one of a tool that does largely the same thing, pick one.
  3. Keep a spreadsheet of all the user research tools you use. Review this spreadsheet every three months or so. You’ll probably only check it if you setup an automated reminder for yourself.
  4. For more one-time research, try to see if there’s a way you can conduct it with your current tools before paying someone else. Sometimes the third-party tool will save you time, most of the time it won’t.
  5. If you’re spending more than $1000 USD per month on user research tools, you probably have more than you can manage.

Here’s a few benefits of staying lean:

  • Staying lean is often easier. If you make conducting research easier, you’ll conduct it more often.
  • User research is prone to being re-evaluated during budget times. User research is also prone when a stakeholder doesn’t like a result, which will inevitably happen at some point. Keeping it low-cost on tooling can keep it under radar.
  • Your users have cognitive limits. So does the researcher. You’ll only be able to keep track of so many things at once. Your focus, as a researcher, needs to be planning, conducting, and analyzing user research, not constantly wrangling the technology.

Questions, thoughts? Let us know!

 

User Research Techniques: Feedback Gathering

Leave a reply
Feedback experiment

Feedback experiment (Photo credit: Sune P)

What is feedback gathering?

Feedback gathering is a user-centric practice where participants are asked for their reaction directly. The questions can be targeted to specific components, elements, or processes. Many times, also, the feedback is left open-ended to allow the user to say whatever they’d like.

Why should I gather feedback?

Gathering and reading feedback from users is a critical way to develop team empathy. Feedback gathering provides a channel for users to feel listened to, particularly when users receive a response. Feedback from users can also help find and fix bugs, improve existing functionality, and find opportunities for user research.

How do I gather feedback?

Gathering feedback is quite simple. You could create an email address and place a mailto: link on the page, as a very simple solution. You can send out an email to your email list asking for feedback. You can ask for feedback on social media. You can also make a form, or use a form generator or surveying tool, such as Wufoo or SurveyMonkey. Other platforms existing that allow feedback gathering in more specific formats, such as Usabilla and the tools from Zurb. Many customer support tools also have capabilities for feedback gathering, such as UserVoice, GetSatisfaction, and Google Moderator. If you can think of it, there’s probably a way to get feedback. Everyone likes to share their opinion.

What are the limits of feedback gathering?

Feedback gathering is very much opinion gathering. As with opinions in the rest of life, not everyone feels the same way. It’s probably not a good idea to take one piece of feedback too seriously; it’s better to see patterns in feedback and act on those instead. In a provocatively titled blog post from UserVoice, they mention some of the dangers of acting too quickly or severely based on user feedback.

Unless the feedback is a technical bug, most of the time it’s better to resolve the issue for the individual rather than systematically. If you get a larger number of feedback requests for a particular issue, the first response you should have is to conduct user research, not to start building.

Feedback gathering and surveying are two different techniques. Feedback gathering focuses on an item that already exists, such as a wireframe or site navigation. Surveying can also focus on a specific item, but often will include questions more directed to observing the user’s goals, expectations, motivations, resources, and attitudes.

Always treat the user as the expert

Leave a reply
An blue icon with a graduation cap and tassel.

An blue icon with a graduation cap and tassel. (Photo credit: Wikipedia)

In our recent post on conducting user research with your own users, we mentioned some of the difficulties with recruiting participants for studies. The most important thing to do is to recruit your own users. The next most important thing you can do is, in copywriting, always treat the user as the expert. This tip works wonders for interface design as well as user research recruitment. What does that mean? Take these two survey copies:

We value your input as a customer. Please fill out our survey.

Compared with:

Got five minutes? Help us make our app better with a few quick questions.

Having tried just about every copywriting strategy for recruiting users, we can tell you the second one is far more effective. Why? Because rather than limiting the person’s role to “customer,” you’re asking them to help you, and you’re telling them in general terms how you’re planning to use the information. You’re implicitly saying, “you know something I don’t.” Which, if you can put your own ego aside, always ends up being true.

This isn’t just for invites either. Treating the user as expert works for usability testing copy, survey questions, study instructions, navigation systems, calls-to-action… you name it, treating the user as an expert and focusing on the benefits of the action will almost always get results.

Questions, thoughts? Let us know!

User Research Techniques: Card Sorting

1 Reply
Card Sorting

Card Sorting (Photo credit: Dunk the Funk)

What is card sorting?

Card sorting is a user research technique where users organize a collection of items, or cards. The data from how each user has organized the cards can then be analyzed into a cohesive whole.

Why should I conduct card sorting?

The card sort analysis can be used to improve navigation, site maps, page organization, page layouts, page flows and process, copy organization, and even to reduce clutter. Card sort analysis can also be used to identify business priorities and use the terminology your users would use. Card sorting belongs with usability testing and qualitative surveying as one of the most often practiced user research techniques.

How do I conduct a card sort?

Card sorting is conducted in person or with an online tool.

  1. Define the problem or target.
  2. Create a list of 20-50 cards you need your users to sort.
  3. Invite participants to sort the cards into categories or groups; record each response.
  4. If you’ve done your study in person, input the responses into an analysis tool.
  5. Analyze the results and apply.

In person card sorts can give you more perspective into the users thoughts and the difficulty of placing certain cards. Online tooling makes the process easier, meaning you’ll probably invite more participants and conduct card sorting more often.

Dendrograms are likely the most productive analysis visualization.

What are the limits of card sorting?

Card sorting falls slightly on the opinion over behavior side of things. When you conduct card sorts in person, however, it’s clear that arranging items is a unique cognitive process and is probably equally opinion and behavior.

Card sorting is significantly more objective than most other user research techniques. That said, you may need to go deeper into the reasoning behind certain relationships. Because of this, card sorting works very well with qualitative surveying and usability testing.

What do I need to know to conduct a card sort?

You’ll likely want at least 10 responses per study. Typically, the results won’t change much, if at all, after about 30 or 40 responses.

Most card sorts are conducted open, meaning the users are free to define their own groups. Closed card sorts are also possible, meaning you would define the groups ahead of time and have the users place the cards within the groups.

Resources and Links

Thoughts, questions? Let us know!