Phase II: Define

22Apr08

Attached are the slides presented. Pause it if you want to read the slides

Looks like it’s time to define things. We finally nailed down the requirement and needs, and at this stage we are beginning to do some user research. What are our user profiles? And developing personas for users(this one’s quite a walk down imaginery lane ).

Let’s see, as with the Discovery phase, we never seem to get things right the first time… and sometimes even the second time. It was quite clear as we developed the user-profile that he was going to be someone who has to juggle a number of different responsibilities in life, frequently on the move because of these responsibilities. We decided to further scope the user down to students, a profile which we were intimately familiar with So we began to look at University Students who were taking up come form of CCA, or involved in an external organisation or community(like a church or a sports club) and perhaps even a part-time job of sorts(tutoring, etc…). As we develop personas, we began to realise that perhaps the best users attracted to our products, may not be those who already use some more refined personal form of management tool to deal with their rather hectic schedules and are in some sense relatively successful. Rather, we realise that our product would really appeal much more to those may have tried to be productive but still feel that they are falling short of it. They may not be very educated in managing their time, but because they are not deeply entrenched in some existing method, they would be more willing to try as well as more adept to try our solution without having to unlearn their previous knowledge of productivity-management. The other anti-persona we developed, Osman, who was the epitomy of a free-willing spirit, we thought was just the right person who won’t use our product. It turns out we were wrong about the way we defined an anti-user. What actually got us thinking was when we realised our previously defined advance-user who may already have some deeply entrenched method to work out her currently extremely hectic schedule might just be our anti-user, as she would be resistant to have to unlearn and relearn a new method that she wouldn’t be sure would be as effective or more effective then her prior methods until she tries it. Mind boggling, all this user persona stuff. We found the process more iterative then a set and done deal. our user persona’s helped us to really clarify who we were designing this product for and why.

From there we seek to define the requirements. User requirements and Functional Requirements. With a clear user in mind the user requirements and functional requirements did not seem to far off. We knew it needed to be light and portable so it would be brought about everywhere. We know our product had to look good to use, as there was no point in an ugly solution that was an eyesore to use everytime. It had to work with the way students work. It had to functionally track events, appointments and tasks. It had to functionally be an agent to help kick-start the process of planning their tasks and appointments to be more productive. It had to functionally aid the planning to be better and easier.

Our experience strategy then came to simply crafting an experience that will enable the user to feel empowered, a sense of accomplishment, a sense of order, an uplifting positive feeling, a short and sweet feeling. No drawn-out process of planning.

Filed under: Uncategorized   |  Leave a Comment