Summary

In the first post in this three part series on Entaggle I discussed some UX (User Experience) and usability issues with its two main focal points: The landing screen and public user profiles.

This post will focus on UX and usability issues again, this time though we will look at process flows and common actions that the user may take throughout the application and highlight flaws in those.  We will also look at techniques we can use to reduce the cost of enhancing the user’s experience.

The final post in this series will look at the business model behind Entaggle, providing suggestions for improvement.  I’ll finish this post with my conclusions on Entaggle.

Major Changes

So since the last post Elisabeth Hendrickson has been hard at work, making some major changes to Entaggle.

View of the new changed Entaggle home page.

Ignoring the right hand pane for now you’ll immediately notice a new tabbed navigation mechanism.  Fantastic!  We now have a common paradigm to navigate the site.  This was one of the main issues we highlighted last time around, so it’s good to see Elisabeth was already working on that.

Identifying UX and usability flaws

So let’s move onto the flaws with common actions and flows the user might want to take throughout the application.

In order to keep this post focused to what is important we will list the three most common actions that a user might want to take.  These being:

1. Tagging another user.
2. Viewing existing tags or users.
3. Creating a tag.

Tagging another user

The process of tagging another user in Entaggle is fairly straight forward.  The quickest way is using the “Tag Someone” tab which invokes a three step wizard.

1. Select a user you want to tag.
2. Select a tag you wish to give them.
3. Confirm the tagging, which also includes the option to add a comment.

Another method to do this is when you are viewing a user’s profile, a list of tags you can assign to that user will appear in the right hand pane next to there profile.  You can tag them directly from this page by simply searching for, or clicking on a tag.  This is a little faster if you are already viewing someone’s profile, as you skip the user lookup step, it also lets you give them multiple tags quickly.

Process flow of tagging someone in Entaggle

It’s all very simple, and has some nice usable features such as the suggestions appearing as you type in a username to search for, or a tag that you want to tag someone with.

Bulk tagging

What happens though if I want to assign multiple tags to a single user?  Or even a single tag to multiple users.  Or better still multiple tags to multiple users!  Well I can’t can I?  Or actually I could!

Tagging wizard step one, with new add another button.

By simply adding the option to add more than one user into the first step of the wizard, you instantly increase its usability.  Now you no longer have repeat the wizard to tag someone else with the same tag.  Of course there are many ways to do this, having the add another button is only one suggestion and you’d also have to account for a way to remove users, such as a X icon next to their name.

Tagging wizard step two, with new “Add another” button.

Like wise the add another button would work for step two of the wizard, when we choose our tags.

The final step which lets you confirm the tagging presents a problem as you’d not be able to add unique comments in its current implementation for bulk user taggings.  You could however get around this with a couple of option menu’s which would allow you to still add unique comments for individuals, or a generic comment for all.

External users

There is another problem here.  What if I couldn’t find a user in the system but wanted to tag them anyway?  It’s a valid scenario and one which would enhance not only the user experience but also the products business model.

Suggestion for tagging an external user.

You can see an example above how this could look.  I’m sure there is a better way, as my mock up here looks pretty ugly to say they least, but the general idea is still very valid.  Upon completing a tagging of a user not in the system, that person would be emailed an invitation, which would include in the body of the email any tags that they’d been given, and the reasons for these taggings (if any).

Viewing existing tags or users

The people and tags tabs allow you to view a list of all tags or people.  The users view has a search option, the tags strangely doesn’t (let’s add it).  Both present a paged view of users or tags, each displaying twenty per page.  Each allows you to drill in to view either more info about that user or tag.

Providing context relevant information

The major problem with this paradigm is that it’s a view of everything; in essence an information overload!  One of the main problems I’ve had with Entaggle in the past was being able to find people that I know, quickly.  Sure I can manually search for every person I might know, but some more clever stuff could occur to make that information more readably available to me.

As we have the ability to list a Twitter profile on our Entaggle profiles we could make good use of the twitter API and find people that we currently follow and highlight them in some way on Entaggle.  I’d previously talked about a watch list in part one for filtering news events to be more specific to your needs.  Using the matching results of our Twitter followers and Entaggle users we could have a suggestion list of users for our watch list.  The watch list in essence would become your Entaggle version of Twitters followed users, or Linkedin connections.  If we don’t like the idea of a watch list, we could just have a tab in the users list which is titled “People you may know.”

By allowing some sort of community interaction in terms of context relevant and watched users, people will immediately relate more with the application and want to come back to watch the people they follow.  Dropping in the customised events news on the home page based upon your watched list (as we discussed in part one), the user will now easily see when a watched user has been tagged or has tagged someone else, as opposed to the entire community wide Entaggle users news view.

Categorisation

Now at least we have one mechanism of bringing more relevant users to our attention and this is a really important factor because as Entaggle scales to one thousand, ten thousand or even one hundred thousand users, this user list will become less and less useful to the user.  Currently it’s already difficult to be aware of who to tag with just over two hundred users.

Another suggestion to bring more context relevant information to the user, would be to categorize users.  If you expand the users profile that little more to indicate what type of industry they are in (there is lots you could do here this is only one suggestion) you could then follow up on the “people you may know” idea that we discussed for the Twitter API idea, from linking a users industry type with other users in that industry.

Likewise the same issue applies to tags, as they scale it will become more and more difficult to find relevant tags for your industry type.  Even now with mostly developers and testers using Entaggle you still get very obscure tags such as “Manual Manic” (someone who executes tests manually).  How would you know what this tag meant from glancing at it’s title?  How would you ever know that if you weren’t a tester, or even in IT for that matter?  You could be a doctor even!  If the hope is that Entaggle will be adopted by all career paths over time, then this is something which needs sorted now.

This really does highlight the need for categorisation of tags.  Just now we are seeing a mix of personal, career and fun tags.  At least when the larger internet community comes around to adopting Entaggle, with tag categorisation I’d still be able to find tags of interest to me easily.

How you display tags by default is another thing.  If a user profile that you’re viewing is a “Lawyer” then perhaps it would be wise to display by default only tags which are categorised as belonging to his field.  You could still present a checkbox to display all tags if you like, and it would probably be sensible to do so.

You can be less clever about these things and simply go with a filter criteria to sift through data, just like what is used on sites such as Linkedin and Ebay.

By making things more context sensitive you greatly enhance the user’s experience.  When we consider a greatly increased user base, it’s essential to provide some level of context sensitive data, otherwise the product becomes unusable and runs the risk of a rejected system.  After all people will always look for a reason not to use your software.

Creating a new tag

The process of creating a new tag is extremely simplistic.  You simply assign the tag a title, a description, some requirements (what would be required to get this tag) and the type of tag it is (private, public or self taggable).

Having previously spoke about the need to categorise tags, when you create a new tag you’d want to be able to select a category or categories that it would belong to.

Another quick win here would be to add a button called “Add another” next to the confirm button.  Why?  Well if I want to add more than one tag I’ll hit confirm, then be navigated away from this screen and be required to select the “Create a new tag” tab to return again.  The add another would simply save the tag you created and blank the form inputs allowing you to add a second tag without having to navigating away from the screen.

Other than that I think this screen works well.

Cheap techniques to analyse user experience and usability

I’m conscious that I’ve talked a little too much already so I’ll keep this section very short!

Wireframe usability evaluations

If you haven’t heard of a wireframe before, don’t worry.  They are simply quick mock-ups of a UI screen.  In fact there is a fantastic tool on the market just now called Balsamiq which allows you to rapidly mock up high quality wireframes.  If you don’t like the idea of spending a lot of time trying to draw wireframes then I’d highly recommend having a look as Balsamiq.

The idea I had around wireframe usability evaluations was simply as follows:

1. Generate a wireframe for each screen in the proposed feature before you write any code.
2. For each wireframe take note of any navigation elements on it such as buttons that take you to another page.
3. Add this wireframe onto a html web page.  For each navigation element add links appearing below the wireframe as hyperlinks to another wireframe that the navigation link would have went to.

From having a wireframe for each screen of the proposed features and having links to navigate you between each for any of the navigation links on that wireframe, you have essentially built a working model of the proposed feature.  You can now begin to test the flows and highlight any issues found, make changes and retest to evaluate those changes, all at very little cost.

If you want to make better use of it, devise a list of end goals you want a user to achieve with the feature (e.g. create a new insurance report) and get some users who have no knowledge of the system and observe how they achieve or don’t achieve these goals.

Paper Prototyping

I’ll not go into this in too much detail, but it’s essentially the same as the above technique with paper, and moving components.  If your wireframe had a button that moved some other element on the screen whilst remaining on the same screen, you, acting as the computer would simulate this motion to the evaluators of your system (this is the moving components part).

This takes a little longer but will give you much better results.  Find out more about it at the Paper Prototyping site.  Jeff Patton also wrote an excellent article called “Test software before you code.” around Paper Prototyping, I’d highly recommend you give that a read.

Community Forum

Just as I was finishing writing this up I noticed Elisabeth has created her own community feedback forum already, so you beat me to that one

Having a community feedback forum doesn’t only just allow for feedback on UX and usability issues, it also adds a sense of direct involvement with the owners of the product making users feel more attached to it.  So this is a very valuable asset, and also enhances a companies business model by developing bonds with your users.

Usability evaluations

Scaling up in the cost of feedback now would be a usability evaluation.  These are very simple and can be done in a day or half day, the feedback though obviously takes a lot longer to analyse and work out what should be fixed or not.

It’s a very simple process:

1. Write up a list of goals for the user to achieve.  For example “I want you to tag one of your colleagues”.
2. Get five people (you don’t need more than this) who have never used the system before to be involved in the evaluation.
3. Communicate with them the aim of the evaluation and what they will need to do.
4. Let them loose on your application.
5. Observe and be available for any issues that require your assistance to resolve.

You can go crazy with usability evaluations and have dedicate labs with expensive technology that tracks users eye movements, but honestly, a quick cheap evaluation will work wonders!

Remote evaluations

This one is just like the above technique, but requires one to one involvement as the user will be testing from a remote location.  The good thing about this is that with screen sharing software you get to see how the user interacts with your software.  Better still if you can record it, to analyse again at a later date.

What’s next?

Next up we’ll look at the business model of Entaggle and provide some recommendations for this.  We’ll finish up by drawing conclusions on where the product is just now and what needs resolved urgently to allow it to be a success.

Thanks for reading.

Summary

Part one of an evaluation on a new and innovative product called Entaggle.  This post will evaluate the usability and UX (User Experience) of its main focal points: It’s landing screen and public user profiles.

Part two, which will follow shortly will look at typical actions and flows a user might want to take throughout the application.  I’ll highlight more flaws and provide suggestions to overcome these.  We will also look at ways to test our improvements cost effectively.

Part three, which will be the final part in this series of posts will look at the business model behind Entaggle, providing suggestions for improvement.  I’ll finish this post with my conclusions on Entaggle.

A crazy new idea!

The latest craze sweeping the testing community is Entaggle.  Some of you may have heard of this already, some might not, but basically it’s a peer recognition web site that allows you to tag someone with a tag that you think they deserve.  For example someone that educates other testers might deserve the tag “Testing mentor”, should I think that they are worthy of this I can tag them with it.

Elisabeth Hendrickson of Quality Tree Software appears to be the driving force behind this innovative product with some early contributions also provided by Dale Emery.  They appear to have taken the approach of deploying with the most basic functionality possible and building it up via previously scoped requirements and user requests whilst introducing new functionality rapidly via a continuous deployment approach.

A unique opportunity

So why am I writing about Entaggle?  Why does it interest me?  It’s quite simple really, the product is based upon an innovative idea, it’s new and they plan to eventually make money from it.  That there is simply a testers dream!

So I’m going to evaluate the product and feedback on my thoughts in terms of usability, UX (User Experience) and its business model over a series of short blog posts, starting with this, part one.

Getting to grips with Entaggle

When you access the site you’re greeted with a vibrant and simplistic UI.  The process of registering an account, finding people, and tagging others is pretty straight forward.  This is mainly due to two reasons:

1. The product is relatively small; there is not much you can do.
2. The user base being a new product is very low (just over 200 members at the time of writing) so finding people and tags is still fairly easy.

Home page

The home page view breaks down into three main areas:

1. The top pane, which consists of a site logo, slogan and some quick statistics around users, tags and taggings.
2. The main column contains a list of the twenty most recent events, which currently displays new taggings and new members.
3. The side column contains various tasks such as user and tag lists, login and logout functions.  This is context sensitive so if you’d selected a users profile, a list of tags you can apply to them would appear, directly replacing the previous tasks.

View of the Entaggle home page.

Currently the UI fulfils its purpose, although not the prettiest and very list driven it does present information easily.

Initial concerns

As the current community consists mainly of testers and developers, the information presented is relevant and interesting.  When we begin to consider different types of users such a lawyers, doctors or even your local supermarket worker suddenly the information presented here is of less importance and relevance to us.

Events

Certainly from a UX point of view this is one of the initial problems presented with this screen, in that it’s not focused on the current logged in user and what might be of interest to them.  Of course the product doesn’t fit well to this line of thought currently, but as user profiles expand, much more context sensitive information can be gathered such as the type of industry they are affiliated with, the company they work for, their interests.  This would allow a more context sensitive view of information which would enhance the users experience, rather than them being presented with an event lists which they would train themselves to ignore.

Another idea which would reduce the need for profile expansion would be a watch list.  You could add users, tags, or tag categories (we’ll get to that in another post).  By default the user would see everything, but they would have the option to configure a watch list to filter out events which are of no interest to them.  After all they merely want to cyber stalk here!

There are a few other minor problems with the events list.  For one it’s static and requires a page refresh to view new content.  It would make sense to dynamically display new events here.  This would lead onto another problem, and one which still exists using the manual page refresh method in that how would you know at first glance which events are new or not?  Twitter has a nice way of dealing with this problem in that they provide a clickable graphic which displays how many new tweets you have.  Lastly you can’t see older events past the current twenty latest events list.  Seeing older events might not be a problem if we had content filter in place such as the suggested watch list or profile based context filtering.

Certainly for now with the small mainly testing focused community we don’t have a problem.  In a few weeks time though we’ll begin to see the worth of this events list being diminished.

Task Paradigm

The right hand column presents a list of tasks the user may wish execute.  As I’d mentioned previously this is context sensitive, so if you’d selected a users name and navigated to their profile, these home page tasks would be replaced with a list of tags you could assign to that user.

So why would this be a problem?  Well when we break down into usability criteria we begin to look at factors such as learnability, consistency and time to execute a task all of these are being directly negated by this paradigm.  Why?  Well tasks such as user / tag lists, user profile and login / logout are actions you may want to take at any time.  However they are not always made available.  Sure this is a small product for now, but as new features develop and we adopt a sense of a premium users feature set, this paradigm will become less learnable, usable and negate the users experience.

Having the main tasks of Entaggle with a blended horizontal logo in a top title bar would serve well for navigation, learnability and consistency.  Linkedin and Twitter both make good use of this paradigm and it works well for them. Both sites are easy to navigate and easy to learn.

LinkedIn navigation title bar

Twitter navigation title bar

Mockup of how Entaggle could look with a navigation title bar

The above mockup is a quick draft of how the title bar could look, you can see instantly it presents a quick means of navigation for the user.  The profile, login and logout tasks have been replace with an option menu with would contain all three.

When you consider that people read from top to bottom, left to right, you can quickly see how the old paradigm of tasks being placed sometimes on the right hand column wasn’t very intuitive.  With the top navigation bar it’s immediately apparent how to navigate the site.

Enhancing the users public profile

Now lets move away from the home page, and take a look at another key aspect of Entaggle, the users profile.

How an Entaggle user profile appears.

As you can see currently we are presented with a list of tags and who has tagged that user sorted by date of tagging with the oldest tag being the first displayed.

Now imagine scaling this up over time, currently I have twenty five tags displayed on this profile.  It already looks a little intense, imaging in a few months you’d come back and I had one hundred tags!  It would be very difficult to get any grasp of my tag collection in it’s current format.  How do you begin to gather a sense of a persons recognition with this many tags?

How an Entaggle user profile could look with some slight modifications.

Now look at the above picture.  With a couple of minor changes this profile suddenly becomes more usable.  All I’ve did is sort the tags alphabetically, and display tags that appear more than once on the one line with the users who have tagged me appearing in a comma separated list.

Immediately it’s more useful, with a simple minor change.  Should someone want to view my profile they can quickly gather more relevant information about me, and begin to identify trends.

A modified Entaggle user profile with tag notes.

When someone tags you they get the chance to leave a note about why they have chosen to tag you with that tag.  This is a key element of Entaggle and currently we can only ever view the reasoning from the events list on the home page, which we already know is non filterable and capped at the last twenty events.  So we are losing out on a key feature and a very relevant piece of information here.  By adding the ability to view the reasoning behind a tag to the users profile (as highlighted in the picture above by a notes icon) we enhance the users experience.  We also cover a possible future scenario where a recruiter might want to drill into your tags to see what your peers think of you.

If you wanted to work on the social acceptance aspect a little more, and if we are being honest that’s one of the main reasons this concept works, in that people want to be accepted by their peers and thrive on recognition, then we could add in rarity factors.

Private tags can only be assigned by people with the permission to tag you with it.  For example I created the private tag “Testing mentor”, currently only myself and a few others can tag people with this.  Why not highlight the uniqueness of a private tag visually in the user’s public profile.  Likewise the rarity of tags might have some visual indication here as well.

What’s next?

I think that makes for a good place to stop for now.  Next we’ll begin to look at process flows and common actions a user might want to take throughout the application, and how UX and usability might be impacted there.  We’ll also look at techniques we can use to reduce the cost of enhancing the users experience.

Thanks for reading.

Summary

In the following post we’ll look at attempting to identify the role a tester plays in a prototyping team.  We’ll discuss feedback provided by the testing community and devise an initial approach that a tester could take.

Background

My workplace has decided to put a big effort on prototyping for the next couple of months.  It’s something new for us as a company as we’ve always just went away and built fully functioning software that’s been asked for.  We’ve never had to prototype anything before.

So certainly it’s a step out of the comfort zone for everyone involved.  One which will require a lot of thought and collaboration from all parties involved.

For myself as a tester it makes me question where I belong in this team, since a traditional functional testing effort will have less importance here; something which would have took up a large amount of my time previously.  I can certainly think of places where I can provide value; however there is still a lot of uncertainty in my mind as to the role we play.  It’s not a traditional test effort for sure, and requires a new approach.

So what role does a test play in a team developing prototypes?

It’s something both myself and my colleague Stuart MacDonald wanted to find out.  So we sat down and had a brief fifteen minute discussion on what roles we could play to provide value to the team.  Jotting down a mind map of our ideas on some paper, we quickly identified some crucial areas we could provide assistance in.

Insights from the community

Now I’m sure other people out there will have a lot more experience than us when it comes to the role a tester plays in a prototype team.  As such I turned to twitter for assistance asking “How does a tester fit within a prototype team?”  A bunch of people responded, and the insights they provided were very helpful for me, helping me clarify thoughts in my head and introduce new ones.

Proactive Testing

Albert Gareev highlighted the need for prospective testing skills.  Prospective being something I refer to as proactive testing.  Certainly, proactive/prospective testing is essential here!  But to what extent?

Feeding back on requirements

As testers a key role we play is gathering information, assessing it and providing feedback on it.  For a prototype team we will have some form of requirement, or even a vision if you like?  So thinking proactively around the testing we could do for a requirement, we could review whatever information we currently have and gather any addition information that we need, review this and provide feedback on it.  Or for a vision we could do exactly the same but obviously put more emphasis on information gathering and collaboration (questioning stakeholders) in order to provide our feedback.

So now as a result the feedback, or feedback cycles we have provided will have helped stabilise scope, reduce risk, and most fundamentally assisted in determining exactly what the end goal of the prototype will be.

Collaboration and determining business expectations

Is that as far as we can go proactively?  Of course not!  Prototyping will evolve over time.  A good approach to prototyping will involve lots of interaction with it’s stakeholders to make sure essentially that the prototype meets their expectations, or at least indicates early when expectations are not achievable.

An approach we can take as testers here is to begin thinking of the difficult questions a stakeholder might ask of a prototype, and asking them early!  From doing so we reduce the risk of developers being embarrassed and the stakeholder being upset.

Our teams are being asked to produce something demonstrable, which can be picked up and demoed to customers by our demo team.  As such we already have an expected outcome placed upon us from the start.  So we could begin asking difficult questions around the business expectations of the prototypes such as:

• “Are you happy to invest X amount of time in throwaway but demonstrable code?”
• Do you expect anything to be reusable from this prototype?
• Are you happy to invest knowing that what is being asked might not be achievable?
• If you do expect some re-use what are the non functional requirements of this prototype.
• Are you willing to fully commit to making these a success via frequent collaboration?

Feeding back on visuals

Rob Lambert and Peter Haworth-Langford stated that testers could play key roles in providing input to designs, process flows and UI.

I agree, and although some might question if a testers role is to input on design decisions at all, I think it can be essential at times.  We might make suggestions for improvement here around usability issues we’ve identified, or realise that a piece of design or in fact the overall design itself doesn’t actually provide any business benefit.

Process flows can be mapped out early from requirements if we have wire frames.  If we don’t we can communicate with the stakeholders to determine the process flow of the proposed prototype.  From assessing these flows we can identify usability concerns early, for example could the flow to point X be quicker if we combined points C and D?

UI, of course there is a lot we could feed back on early here.  We could even check if our competition is doing something similar?  What makes their paradigms special?  How do we make ours better?

Preventing rejected systems

The following two I liked a lot:

• Anders Dinsen stated “The tester understands the objectives, but questions the means to get there because he sees the problems.”
• Jamie Cuthbertson stated that a tester’s role should be to challenge assumptions, viewing things from a different perspective and making suggestions for improvement to the product.

Anders highlights the need for a tester to think of the bigger picture.  It’s a difficult job that in itself, and for a prototype we’d need to fully understand what the business expectations of the prototype are first before we can begin to see if we are on the correct path.

Jamie correctly highlights the need to challenge assumptions.  I’d like to add to this “assumptions that matter”.  Certainly for a prototype we will be looking at things from a different perspective.  I’m still unsure myself what perspective we’ll take, but for now I see myself and my colleague Stuart being focused on making sure that the end delivery satisfies business needs as opposed to individuals visions, or worse still conflicting visions.  After all it’s easy for a prototype to free-fall into something which sounds and looks pretty but delivers no business value as it doesn’t actually solve a problem, or one that’s worth solving.  Peter Haworth-Langford highlighted on this when he said that we should be making sure this is actually something someone wants.

Peter Haworth-Langford also added that a tester’s role might be to help a customer or stakeholder formulate their concept.  I think that’s a very good point.  We could collaborate with them to generate scenarios, persona’s and solid use cases around their proposals.  This in turn would help identify if their was a solid business case for the prototype after all.

Functional test involvement?

Basim Baassiri highlighted that testers could provide feedback by doing exploratory tests.  Stephen Hill said something similar when he stated that they could look for areas where the prototype might break.  I agree to an extent here, and if the prototype is being demonstrated as its being developed we could provide assistance here to avoid embarrassment during the demonstrations.  Of course exploratory testing doesn’t just stop at functional testing, from providing feedback to the requirements we will be exploratory testing as well.

Alternative prototyping

Markus Gärtner asked a series of questions to help him understand the definition of prototyping in my company.  In one question I responded that traditional functional testing would be of less importance here, to which he asked “So, how would you test a teleporter like the one from NCC-1701 D?”  To which I replied that it depends on what this prototype teleporter was required to do.  As a prototype it might not even need to teleport at all.

A famous modern example of prototyping without actually having a working model comes from none other than Apple, who had created several initial prototypes of a proposed iPod design out of foam.  Drawing the controls on the front they used these foam models as if they were actual real working mp3 players for some time.  Walking around with them and pretending to interact with the controls.  This allowed them to understand if the actual look and feel could be appealing, prior to investing in a working model.

So what is the role of a tester in a prototyping team?

To get more of an understanding of the role I’ll be playing I’ve generated a mind map below.

This image has been cropped, please select it to see it in an expanded size.

Suggested approach

So the Twitter testing community provided me with a lot of help in identifying what a testers role should be in a prototyping team.  As the above is just a collection of my thoughts on peoples responses I’d like to see if I can model an approach of some kind, and hopefully you can help me some more by providing feedback on that.

Step 1:  Clarify business expectations

We need to quickly identify what the expectations on a prototype are from the business.  Hopefully this will have been done already, but if not we’ll have to input these into the chain of command.  Some example questions here might be:

• What deliverables are you expecting during or at the end of the prototyping phase?
• Are you expecting re-useable code?
• If something is not realistically achievable in the given constrains how will you react?

Step 2:  Feedback on requirements or gather an understanding of visions.

Obviously as information gatherers we will identify and feedback on potential issues, gaps and risks with the information we have.  Most importantly we’ll be in constant communication with the key parties involved in this prototype, keeping an eye out for conflicting information.

Step 3:  Validate designs

Often a prototype can have little or no requirements.  We can assist both the developers and the stakeholders here by helping (in collaboration with the stakeholder) produce real life scenarios of how a customer would use the proposed prototype.  We might produce persona’s as well, to highlight the different kinds of user of a system, and in doing so validate our paradigms against these, and uncover potential usability issues.

Step 4:  Determine functional test involvement if any

We might be able to assist with functional testing of a prototype prior to stakeholder demonstrations.  There is a high possibility that our input here might not be required at all.

Step 5:  Ask the difficult questions early

This can be two fold.  We can assist developers by putting ourselves into a stakeholders / business mindset and thinking of possible questions they might ask of this prototype.  If the prototype has frequent progress demonstrations (and it should have) to stakeholders, we can ask the difficult questions of them also.  For example the prototype might be at risk because a clear decision has not been on a paradigm to use, we can ask why that decision has not been made and when it will be made highlighting that the project is at risk by the decision delays, and clarifying that their expectations will not be met if this progresses.

Step 6:  Track expectations

As a prototype might have one or more stakeholders, combined with other people wanting to input their ideas, we’ll need to do our best to keep track of the initial expectations, and make sure if these change that everyone is aware of it and in agreement.

Step 7: Be aware that business expectations may change

Even the best laid out plans for a prototype may become obsolete overnight if the expectations of the business change.  They might like the concept so much that they decide it should be part of the product, and ask that you begin building it in production standard code, which comes with a large test effort in itself.  Likewise the concept might be sold to a customer and require all current prototyping efforts to be dropped to work on developing this sold concept for the customer.

Thanks for reading.