1. Find a (real!) user of your product, that you believe to be more-or-less an "archetype" of a class of similar users
2. Start writing down his(her) workflows/ how (s)he uses your app/what (s)he's trying to achieve, etc.
AFAIK my company is even preserving the real first name of the "persona". If we're talking about real people, then it makes sense to use their behaviors/needs to guide the design of the product. If we're talking about imaginary people... well, you're just optimizing your product for some imaginary user :)
Unfortunately, not so simple in my experience. That's a lot of time and money many companies can't or will not fork over. So, shortcuts and approximations are used as an alternative.
What definitely costs companies a huge amount of time and money is launching new products or concepts into markets - especially without some form of pre-qualification i.e. is there a need? does this solve a problem? will customers actually pay for this service? etc.
As the old user experience adage goes: "spend $1 on usability and save $100* down-the-track".
* made up numbers :)
Through research, one of the personas that fell out was "man with a van", that is a sole proprietor who did most of their work out of their van. Two key insights were:
1) The median age was higher, being in the 50s they were starting to thinking about the retirement and handing over the business. Even if they had little interest in engaging with digital, their protégé would, and ignoring digital would mean losing market share in the future.
2) They were on the road a lot, and mobile-based experiences would be helpful over having to call/fax orders, bills, etc. However research showed that their biggest complaint was the small size of UI elements for both reading, and more importantly clicking on (lots of complaints about how hard mobile website were to use with fat fingers).
I hope this was useful; I find well developed personas useful to keep in mind the disparate users of a system, what they are trying to achieve, and how. There was a comment about validating personas as part of user stories, which I'd recommend.
Something like this, fleshed out with more detail, would have been great to include in the original article. It shows how personas can be a useful framework for exploring potential markets (or niches, maybe).
It's useful, to me at least, to come up with personas that are based on clusters of customers (based on research) so that every design choice can be validated against the impact to them. Each persona may have a different goal or priority.
The other use is when thinking of scenarios for personalization, what data can be used to segment customers?
It might be useful to have a dashboard on the homepage showing the status of POs and bills for somebody in purchasing vs. showing previous items ordered to facilitate reordering for somebody else.
I find that a lot of people like to sit down and play "let's pretend" instead of doing real work.
Personas come across as an easy way to get sidetracked by a game of "let's pretend." That's when personas are just stereotypes.