Interactive Prototypes using Silverlight Sketchflow

A picture is worth thousand words AND a prototype is worth thousand pictures. I have recently read a book by Tom Kelley who works with a leading design firm called Ideo from silicon valley which has been instrumental in designing many great products. The book also emphasizes on an early prototype that can be shared with the customer or end user to avoid an expensive last minute change or surprise.

In this blog I will touch upon Microsoft’s Silverlight Sketchflow Tool which offers an easy to build prototypes for Silverlight or WPF Applications. This blog is for Silverlight based application prototyping.

1) Launch Expression Blend and create a new Silverlight or WPF sketchflow application. A default node is created for you which could be changed to home page after right clicking on the node and selecting the option from context menu. Hover on the node and there are four options available. Selected the first one to create a connected screen

2) In the example below, I have created several connected screens from Home Page such as About, Careers, Products etc… Also provided different color options using the option ‘change visual tag’

3) I also used ‘connect existing screen’ option whose purpose we shall watch after running the project. This is primarly for related nodes(screens)

4) By double clicking each node, I am able to add objects, images etc… for presenting the interactive nature of prototype

5) Used the Sketchflow animation feature to record a simple animation that rotates the image for a given period of time. The sample animation was recorded via transform/rotate option from properties while leveraging the transition time and base state option. More on this can be found in my earlier blogs on Expression Blend

6) Finally, for some of the objects placed on the design mode were componentized by right clicking the object and choosing the option ‘make into component screen’ and re-using the same as appropriate and applicable for a different node/screen instead of re-doing the same feature for a given screen. The reason shall be justified once I run the project and when the Sketchflow player is launched. (Note that you need to draw the connector from the component that needs to reuse )

7) Let’s look at the Sketchflow player that is launched once the project is compiled and ran. As seen from the below image, all the nodes are represented along with Home icon, Sketckflow Animation option and a Feedback option. The Feedback option can be interactively used and exported for a later review which is a real cool option to capture notes during the prototype demo

8) Click on the Sketchflow animation and one can see the animation that was recorded in step #5 above

9) Click on careers and click on the different location sub-menu items. Observe that by using the component feature from step #6, we could re-use the control. Click on the About and see how the contact menu persists which is a resultant of the step #3 above in that a connection to existing screen option was leveraged

With these simple steps one could express the design intent and obtain early feedback from the customer. Most importantly, some of the prototype elements could be re-used during the design/development of the actual application development . For instance, the animation part.

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/706

Avoid Dropping the Baton: Use a RACI

At the Beijing Olympics in 2008 both the US men's and women's relay teams failed to advance past the first round of the 400-meter relays. In both instances, the reason was that someone dropped the baton.

In track and field, the incoming runner must work hard to avoid dramatic changes in speed and stay in their predetermined part of the lane. In the nonvisual exchange, it is the responsibility of the incoming runner to place the baton in the hand of the outgoing runner. The outgoing runners position themselves in a stance that will allow acceleration and will allow them to see the incoming runner approach. As the incoming runner hits the mark, the outgoing runner turns forward and begins accelerating. At the predetermined point, the outgoing runner moves the receiving hand into position and leaves it there-keeping it as still as possible-until he has received the baton. The outgoing runner must avoid "fishing for the stick" and should keep the hand steady. The incoming runner can see the hand, and it is this runner's job to put the stick in the right place. But even Olympians seem to have trouble with these complex handoffs.

How many times in our project delivery, do we determine that someone "dropped the baton"? The issues we find in root cause analysis might say "code did not meet standards," "missed requirements," or "bugs not identified until after production release," but what this really means is someone did not do something.

Why? Generally I have found that the key reason is an improper handoff because of a lack of understanding or poor communication. The tester didn't cover this new piece of functionality in his test cases. Oops. The business requirements specification was never signed off by the business. Oops. The project manager failed to communicate the change in date to the client. Oops.

To avoid all these "Oops", I have a suggestion. And I cannot promise it will solve these failures, I can share with you that on projects where this activity has been completed, the handoffs are much crisper because communication has greatly improved.

My suggestion is that the project team takes the time early in the project to complete the RACI Matrix together. For those of you who haven't heard of a RACI (were you sleeping through that in your PMP class? J ), this is a document (usually in Excel) which defines for each project activity, who is Responsible, Accountable, Consulted, and Informed. It's a simply grid but it goes a long way in clarifying team members' roles and ensuring that everything the team needs to do in the project is taken care of. Some of you may be thinking - but everyone knows their role. They have a title and a bullet pointed list of things to do. How nice. And I'm sure everyone on your team read each other's role description in detail and know exactly how they can work together effectively too, right? Good luck with that.

We've started using the RACI on multiple projects at Alliance and I have seen the benefit of teams having open conversations about who is accountable, who the ‘doers' are and who needs to approve artifacts before they are complete.

My top 5 tips to facilitate the completion of the RACI are as follows:

• 1. Make sure you have clear definitions of each letter of the RACI. There are quite a few deviations on the letters. Whatever you agree to, make sure the team understands each letter before starting the exercise.
• 2. List all team members across the top of the matrix (give each one a column!) and make sure each person attends the meeting.
• 3. This should NOT turn into a project plan. List major tasks, deliverables, activities - but know when to stop.
• 4. Allow the (sometimes uncomfortable) conversations to happen between the team members - especially about who is accountable and responsible. What may happen is that the team realizes where they were dropping the baton. It's really important to determine who is going to take it. A person in the group may realize during the meeting that they were the person dropping the baton. Leave that behind. You are now establishing the new rules of the road.
• 5. Do this at the start of the project - once you know enough about the scope and deliverables to be effective. Revisit it from time to time - especially when you are starting to see deviation.

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/705

Zombieland and Rules for Customer Service

(As I proofed this blog, I became concerned people would think I was calling my customers zombies. Far from it. I am only using the current pop culture theme of zombies humorously to portray some of my heartfelt rules for customer service. Please keep this in my as you read my first blog entry…)

The main character in the movie Zombieland, named Columbus, has mastered survival in a post-apocalyptic zombie world largely due to his obsessive compulsive traits.He attributes his unlikely survival to a list of “rules” he authored to survive a place where zombies significantly outnumber humans. Columbus' ability to remain alive is the reason he is one of my customer service heroes.

Columbus’s Rule number two is “Double Tap”, meaning one gun shot to a zombie is usually not enough and should be followed up by a second pop. This sums up one of my main customer service rules which I now call “Double Check”. After correcting a technical issue with a customer, I always try to check back a second time to make certain the issue did not re-occur and to see if there are any follow up questions. Any question I can answer often averts a major issue in the future or reveals a new problem that hasn’t become crippling for the customer…yet.

Rule number 8 is “When in Doubt, Know your way Out” refers to making certain one knows the way out of any building or room, so that it is faster to escape zombies. Zombies can pop out anywhere at any time. If you are prepared with an exit plan, you have one less thing to worry about. Same is true for customer service issues. One time I received an urgent tech support call while in the men’s room. The caller needed the password for the encryption software and was on the way to meet with the client. I was able to address the issue at that moment because I had already put the credentials into my Blackberry.

Rule number 10 is “Check the back seat”. In a zombie infested world, it is a common escape tactic to jump into any car and speed away from a horde of ravenous undead. However, the effectiveness of this is negated of there is already a zombie in the back seat. Checking the back seat is also a wise customer service move, and can lead to more customer service satisfaction if done on a regular basis. For example, if you find yourself with a client correcting an issue, always check to see if there are any other problems you can fix while you are there. This is particular stunning when you fix an issue the customer knew about and another one they missed.

Rule number 11 is “Enjoy the little things”. Surviving in a world full of creatures that want you to be breakfast, lunch, dinner, and snacks is demoralizing and can make you crazy. This, at times,is the world of customer service. So take the time to enjoy customer service successes and the praise from a satisfied client.

I am not saying that customers are zombies (although many would argue they sometimes act like them – I am getting to this point soon) nor am I saying customers are soulless and hell-bent on eating customer service reps alive (well, maybe deep down we all feel that sometimes but I will discuss that in a later blog.) I am saying all of us can act like a zombie when facing a crippling issue. If my hard drive crashes I cannot do any work and I am consumed by this one need to get back to work; any delay in resolution makes me more and more crazy, much like a zombie.

Please post any experience you have had in which you helped a zombie or became one yourself.

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/704

Managing Customer Expectations

As I had mentioned in my post on defining project success, one of the potential measures for project success is Customer Satisfaction. And one of the most powerful ways of achieving customer satisfaction is to manage their expectations - not only at the start, but throughout the entire project. In order to manage their expectations, it helps to do the following:

◊ Ask Questions!: The best way to understand what your customer is expecting is to ask questions. Lots of questions! Not only do you need to capture their explicit expeciations, but there will always be implicit expectations that a customer will forget to mention. It's up to you to ask enough leading questions to capture those expectations. To figure out what questions you should ask, you need to put yourself into the customer's shoes and think about what your expectations might be.

◊ Pushback!: Not every customer expectation is going to be reasonable. It's up to you to let them know what is achievable. That doesn't mean you should say no to what they want, it means that you should work with your customer to meet as much of their expectations as possible, and be honest with them about what is not.

◊ Set up a Feedback loop: Take as many opportunities as you can to ensure two-way communication with your customer that allows you and them to provide feedback to each other. For instance:

● Document: After you think you understand your customer's expectations, document them in your own words and provide them to your customer for review. When something changes, as it inevitably will, document that as well.

● Build a prototype: As I discussed in a previous post, prototypes are great for fleshing out requirements and making sure that you are on the same page with your customer.

● Provide interim releases: The great thing about Sprint based development is that at the end of each Sprint, the customer has a working system that they can use and explore, and most importantly provide feedback on. This feedback can be incorporated into the next Sprint. This cycle allows you to keep in synch with the evolving expectations of the client.

-- Lisbi Abraham

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/703

• labraham's blog
• Add new comment

The Role of the Product Manager

As we discussed in the last two posts, one of the key factors in the success of any project is ensuring that each team member is clear about their own roles and responsibilities, as well as the roles and responsibilities of those around them. This time I'd like to focus on the role of the Product Manager. They may also be known as the Functional Representative, and sometimes even as the Subject Matter Expert (SME). However, in the case of the SME, their responsibilities typically don't cover everything that I consider to be integral to the role of the Product Manager. So, here we go - these are the basic functions the Product Manager should be expected to perform on a project:

TAGS:
Program Management
Product Manager
Project Success
Roles and Responsibilities

Website Hacking

Hacking is hackneyed for the hacker, but is a serious issue for corporates whose websites happen to be the face of the company to the external world. Corporate websites are also the point of sale for ecommerce activities.

US.gov websites are the most highly targeted web sites when it comes to hacking. Others are not an exception. A lot of security centric companies invest resources towards ethical hacking to understand a hackers mindset and counter measures thereon.

With hosting service providers being the de facto standard for most of the SME’s web site needs, some amount of control or total control is provided to the customer which might vary as per the contract.

Consider a situation wherein your house was burgled and you lost something which is very priceless such as an old photo album or a bottle of wine that was aged for 15 years and of course cash and expensive jewellery that were the main items of concern. You were procrastinating to get a security system installed or get the Rottweiler or the Doberman to guard your house.

The analogy can be applied to corporate websites as well which if gets hacked could lose price less information as well as information having monetary value. On the priceless front, it could be a prospective partner trying to access your site for potential tie up and on the monetary front : source code, prospective customer visits or any other internal assets. Denial of Service is one side of the story followed by revenue impact and angry users who may never re-visit the site.

Certain fundamental steps shall insure and safe guard your internet site from a potential hacker. These are in addition to what you could insure after using a threat modelling tool coupled with SQL Injection, Cross Site Scripting verification amongst other things.

1) Have a strong password policy for the root user. This should not be limited to special characters, combination of upper and lower case. It is more of a pass phrase. Avoid predictable names such as companyName123, companyName123$, companyName~1. These are easy to crack

2) Disable all unwanted ports such as FTP, Telnet as these could make your site vulnerable for data siphoning

3) Have captcha mechanism where user is expected to fill in information to circumvent automated spam programs

4) Have logic built into your code to identify suspicious IP Addresses OR use a fire wall mechanism by the service provider

5) Make sure, there are no executable links available from the view source option. Media Files that could make a call to the server is one such example

6) Optimize the code to insure media files are not calling the server for content every now and then

7) If using a Linux environment, make sure to have the upper limit of numprocesses, numfiles set to a higher and a realistic value after looking at the lsof output to counter spam hits

8) Peer review of the code OR use a code analysis tool

These simple steps might let you avoid a burglary like a situation that I quoted earlier!
Application Development Services

The Role of the Executive Sponsor

As we discussed in the last post, one of the key factors in the success of any project is ensuring that each team member is clear about their own roles and responsibilities, as well as the roles and responsibilities of those around them. This understanding of their role extends beyond the immediate members of the project team and even to the Executive Sponsor. For all projects, but especially for large projects, the Executive Sponsor is critical. He provides the vision, and usually the funding and some of the key resources.

For the Executive Sponsor, these are the basic functions they should be expected to perform on a project:

◊ Visionary: The Executive Sponsor needs to provide the vision for the project. He needs to have a view of how the project aligns to the corporate goals and benefits the organization. He should also be able to articulate the project's overall objectives.
◊ Champion: The Executive Sponsor needs to be the project champion. Especially for projects that require a change in the organization or a change to a business process, the Executive Sponsor needs to be the champion who reinforces to the entire organization that the project has executive backing and that they are all expected to support the change in the interest of the project goals.
◊ Fullback: The Executive Sponsor will be the fullback for the project team in general and especially for the project manager. He will block obstacles and distractions from impacting the project team, and he will clear the path for the team to succeed.
◊ Quartermaster: The Executive Sponsor needs to ensure that the project team gets all the resources they need to succeed. The project manager will identify the resources, but the Executive Sponsor needs to provide the backing that ensures that the resources are allocated quickly.
◊ The Pig: The Executive Sponsor needs to be the person who is ultimately responsible for the success or failure of the project. In the adage about the pig and the chicken and their involvement in the making of a breakfast of ham and eggs, the chicken is invested in the breakfast - but the pig is definitely committed. Similarly, the Executive Sponsor needs to be committed to the project, because only then will the project have the attention and focus from the Executive Sponsor that it needs.

Do you know your Net Promoter Score?

As the IT industry as a whole matures, metrics are becoming increasingly important in order to track performance and determine organizational goals around quality and productivity.We spend a considerable amount of time at Alliance measuring what we’ve defined as the RightMetrics: items such as Schedule Variance, Resource Utilization and Defect Density.

I will assert that most companies, especially in Information Technology, DO NOT spend enough time listening to their customers.Equally, if not more important, is what Fred Reichheld coined as ‘The Ultimate Question’ in his book, published by the same name.("The Ultimate Question" was ranked #1 on the Wall Street Journal's Business Best-Sellers List and #1 on USA TODAY's Money Best-Sellers List.)

The single question is as follows:

"How likely is it that you would recommend our company to a friend or colleague?"

The answer to this question can be divided into three categories:

1)Promoters (9-10 rating)

2)Passives (7-8 rating)

3)Detractors (0-6 rating).

To calculate the ‘Net Promoter Score’ NPS®, the percentage of Detractors is subtracted from the percentage of Promoters.

We have adopted the Ultimate Question into our Right Experience customer loyalty program.This is a question we are passionate about asking during our customer online satisfaction surveys as well as the site interviews we conduct face-to-face with clients.

At Alliance we scored a 60, scoring nearly 2x better than our closest competitor. And we won’t stop there.We’re very focused on improving our performance to move every customer into the ‘promoter’ category.

Do you know your score and how you compare to your competitors?

We’d love to hear your questions /comments about Net Promoter and the Customer Experience.