Ranger: Determining the initial feature set using personas, task analysis, and process flows

[Update: Ranger is being launched soon as FreeRange, a freelancer availability management and resourcing app]

As we’ve tried to describe in the previous two ranger posts (first post, second post) we believe there is a need for a resourcing application that helps corral a large network of talent into the sales/bid process, organize them as a well oiled team, and plan for the future resourcing needs.

We went through an exercise internally to try and determine the core of the application. Not only what problem it solves but how it will ease the pain of the user. Before we could determine this nugget we needed to start using the design process we implement on client projects on Project Ranger. The way we have been describing our working process is that we create engaging sites and applications using a blend of research, co-creation, and prototyping. For this project we’re not only eating our own dog food by using our own process but we’ll also be using this app internally first.

User personaTask Matrix

The first step in the process is to perform research. Since we are end-users of this app the research has been conducted over the past year. And that helped us define our users, based in part on us, create personas and list out their tasks in a matrix. A persona is a fictional representation of a user that includes potential demographics, needs, and motivations. A task matrix lists out various tasks a user may perform within an application and ranks them by frequency and importance. Both these research methods allow us to gain a better understanding of potential users and their needs.

Once we understood the personas, we could start to identify the theme of this application, a one-sentence description of the problem we are solving. We wanted to determine the smallest possible useful feature set that we can deliver quickly. That way we can try it out, iterate, and then launch. This is similar to what the Lean Start-up movement calls the minimum viable product. Some might call this common sense but it’s actually an incredibly difficult process, weaning down an idea to a useful, deliverable core.

Some themes we came up with were (1)Enabling your social network to be your project team, (2)Role based resourcing, not task based, (3)RFPs are tricky beasts, get confidence in your estimates, (4)Bidding projects with partners made easy. For the time being we have settled on Ad hoc teams can compete with anyone. It frames the environment really well. Appeals to small firms by reaffirming what they already know (or think they know)—that they can compete. But Ranger offers them a tool to help with the process. We don’t feel like this is perfect but we felt like it was enough to help us move into the next steps, determining the initial feature set and process flows.

Process FlowThe process flows allowed us to begin to figure out how this application would work. What paths the user takes to get to various parts of the application and the results of those paths.

These methods led us to an initial clickable prototype of the application using our favorite wireframing tool OmniGraffle. With this initial verison we can test out the features and see if the flow of the application makes sense. We will make changes along the way, continuing to iterate until we get it right.

Bookmark and Share