Challenge and Selection

When developing new software projects that need to tackle a set of wicket problems,  we simply can’t just ask the customers what they are looking for or to enumerate  their needs. The different stakeholders might have their own thoughts on how the  new system might work, and also different priorities depending on their roles. It’s  also not uncommon the fear for change, and the reluctancy of accepting new  systems or processes that are going to alter their working routines.  It during this discovery phase, where we need to try to ground requirements to a  starting point and try to use the right tools to discover their needs, and mostly to  dimension the product since they are expecting a quote after all.

A tool that has proven to be most effective for us, is a visualization tool called  Wireframes. After gathering some basic information on the project goals and  researching similar solutions we are ready to explore different possibilities the  product could take. Instead of the sequential ﬂow of writing requirements down as a  bullet list, we present them some basic shapes with the required information.  Wireframes are sketches of some of the screens of the desired software drawn in  very basic shapes, like squares for buttons and scribbles for text, that show what  information and interactions the software would display on some basic screens.

Application

These wireframes are printed and then used as a starting point on a co-creation  meeting where we focus on listening their thoughts and incentivize them on using  their pens to take notes and write over the wireframes. This stage is very helpful for  us since they can lead the conversation once they have something to start with. It is  very important that the wireframes don’t include much detail or colors, so they can  focus on the information and not get distracted by design or layout issues. Leaving  empty spaces and not making screens complete also leaves some open questions  so they propose unthought things and also gain ownership on the product they will  use.

Insight and Approach

Recently we used this technique for a government area that needed to manage their  contacts and agenda like a CRM. We based some of the wireframes on commercial  CRM solutions, but after a set of meetings we discovered their focus was different.  Most of the stakeholders wanted to easily get reports on events and contacts and  their focus was towards events and tasks rather than leads which is the case of  enterprise CRM. I think not only the technique helped a lot on getting this type of  insights, but the fact of including many of the stakeholders on the meetings made the  experience richer and broader. In the future we’ll try involving more roles to the meetings and taking color markers  with us so that anyone can write over the wireframes instead of having one lead the  conversation.


Challenge and Selection When developing new software projects that need to tackle a set of wicket problems , we simply ca n’t just ask the customers what they are looking for or to enumerate their needs . The different stakeholders might have their own thoughts on how the new system might work , and also different priorities depending on their roles . It ’s also not uncommon the fear for change , and the reluctancy of accepting new systems or processes that are going to alter their working routines . It during this discovery phase , where we need to try to ground requirements to a starting point and try to use the right tools to discover their needs , and mostly to dimension the product since they are expecting a quote after all . A tool that has proven to be most effective for us , is a visualization tool called Wireframes . After gathering some basic information on the project goals and researching similar solutions we are ready to explore different possibilities the product could take . Instead of the sequential ﬂow of writing requirements down as a bullet list , we present them some basic shapes with the required information . Wireframes are sketches of some of the screens of the desired software drawn in very basic shapes , like squares for buttons and scribbles for text , that show what information and interactions the software would display on some basic screens . Application These wireframes are printed and then used as a starting point on a co - creation meeting where we focus on listening their thoughts and incentivize them on using their pens to take notes and write over the wireframes . This stage is very helpful for us since they can lead the conversation once they have something to start with . It is very important that the wireframes do n’t include much detail or colors , so they can focus on the information and not get distracted by design or layout issues . Leaving empty spaces and not making screens complete also leaves some open questions so they propose unthought things and also gain ownership on the product they will use . Insight and Approach Recently we used this technique for a government area that needed to manage their contacts and agenda like a CRM . We based some of the wireframes on commercial CRM solutions , but after a set of meetings we discovered their focus was different . Most of the stakeholders wanted to easily get reports on events and contacts and their focus was towards events and tasks rather than leads which is the case of enterprise CRM . I think not only the technique helped a lot on getting this type of insights , but the fact of including many of the stakeholders on the meetings made the experience richer and broader . In the future we ’ll try involving more roles to the meetings and taking color markers with us so that anyone can write over the wireframes instead of having one lead the conversation .