Thursday, December 12, 2013
I also want something more lightweight to work with and blogger is a bit heavy for me.
Check me out here.
Monday, September 30, 2013
A job Story is a powerful way to facilitate team conversation and discovery when designing products. They are meant to cut right to the job to be done by eliminating distractions. The job story encourages the product's design process to focus on context, causality and motivations instead of assumptions, subjectiveness, personas and implementations.
As I write more job stories, I've been paying attention to characteristics which make some stories better than others. When a story is well done, it helps me and my team cut right to what needs to be discussed and puts us all on the same page - making the product design process dramatically better.
Here are 5 tips which will help when writing Job Stories:
- Refine A Situation By Adding Contextual Information
- Job Stories Come From Real People Not Personas
- Design Modular Job Stories Which Features (Solutions) Can Plug Into
- Add Forces To Motivations
- Job Stories Don't Have To Be From A Specific Point Of View
Thursday, September 26, 2013
bring focus to the role of a UX Designer, as well as strategies on how to convince an organization that the role of UX should exist.
Sunday, September 22, 2013
Friday, September 20, 2013
*A newer & better version of this article can be found on medium.
I've written about the problem with user stories before. At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I'm working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I've come across a great way to use the jobs to be done philosophy to help define features.
I call them Job Stories.
Thursday, September 12, 2013
Hit, Stand Or Double Down?
Wednesday, September 11, 2013
Monday, September 9, 2013
Testing The Real World
Friday, September 6, 2013
part 1, part 2, part 3, part 4, part 5 , part 6, part 7
I Need A UI
My key motivation is to identify what-I-know-I-don't-know and then design against that until I am satisfied that the conflict I was concerned about has been resolved. For example, I'm not going to worry about how ( or if ) I need to design a log in workflow, instead I'm most concerned about having a UI that customers ( and the consumers they make content for ) will understand intuitively and feel productive using it.
Thursday, September 5, 2013
part 1, part 2, part 3, part 4, part 5, part 6, part 7
Listen & Stay Focused
Wednesday, September 4, 2013
part 1, part 2, part 3, part 4, part 5, part 6, part 7
What Customers Are Doing Now
Tuesday, September 3, 2013
part 1, part 2, part 3, part 4, part 5, part 6, part 7
The Problem Space
When I meet people and they learn that I build products, I often will see their eyes brighten and then I prepare for the question which is sure to follow....
Thursday, August 29, 2013
Saturday, June 22, 2013
Kris Gale recently wrote an attention grabbing article: The one cost engineers and product managers don't consider. The article is long, dips into a few different topics but can generally be summed up as:
Engineering needs to have substancial influence over business decisions. This is because engineers understand a system's overall costs [complexity] better than the business.
Thursday, June 20, 2013
Tuesday, June 18, 2013
Create revenue and cost models for product initiatives.
This made me think about what could be better than using models. After some thought it occurred to me: creating models can be a waste and one of the best ways to combat waste is with the Lean mindset.
Friday, June 14, 2013
What's happend here is the customer has moved from contentment with a current solution, through considering a change, to finally making a decision to either continue to hire the existing solution or to fire it and replace it with another.
This method of breaking down customer behaviour is of very much tied to the 'jobs to be done' philosophy. It's certainly tempting to think of the progression as linear; however, it's not. Forces will pull customers towards and away a new product or behaviour. Depending on the strength, timing and circumstances of these forces, she will either continue to hire her existing solution or she will fire it and use another.
Current depictions of these forces and timelines depict them as linear, but I find it to be a long and winding road... a road which might take the customer back to their existing solution.
I drew up this picture to demonstrate how I see the customer timeline and how those forces pull us towards a new product...or might take us back to existing behavior.
The key is to effectively identify these events and to make the events (emotions) which push the customer towards a new product or behavior stronger than those pushing them towards an existing behaviour.... or to a competitor.
Wednesday, June 12, 2013
Tuesday, June 4, 2013
When working towards product / market fit, you generally start with either a product or a market. It's important to know the difference because one is a bunt and the other is a swing for a home run.
Thursday, April 18, 2013
The missing link is we're going to have an evolution, a synthesis, of thin and fat clients.
Wednesday, April 17, 2013
Tuesday, April 16, 2013
Monday, March 25, 2013
Thursday, March 21, 2013
Tuesday, March 12, 2013
Monday, March 11, 2013
"..in all this time, I haven't heard one mention about the customer or the product. Why then, do these product managers need to spend so much time learning Agile."
Sunday, March 10, 2013
The problem with user stories is that it discourages team communication. It might seem like it encourages team communication, but it really doesn't. They are just another way to avoid talking-things-out and to have disconnected team members push tasks to another.
Saturday, March 2, 2013
Whenever I read someone commenting about the need to remake email or the todo list... one of those "You're doing it wrong" memes pops into my mind.
Email and TODO lists are perfect the way they are, if you're unhappy with them, it's because you're using it wrong.
Sunday, December 16, 2012
Monday, November 19, 2012
Suppose then, that flying cars are on the horizon. All the futurists, and you, agree that they are going to completely replace existing cars and car design. There've already been field tests and the media is gobbling up the latest info - especially when they are available to buy! Now, you run a business which creates & sells cars. How do you go about introducing a flying car that your existing and future customers will want?
Thursday, November 15, 2012
Thursday, September 20, 2012
Saturday, February 11, 2012
...wait...what am I talking about??!! Our monthly roadmap discussions were a NIGHTMARE. All that tension, haggling, posturing, politics… So about 7 months ago, I axed roadmapping. Looking back, it was such a waste of
Tuesday, January 17, 2012
Thursday, January 12, 2012
I certainly did have a suggestion: shut down the server and stop using Ivy.
Monday, January 2, 2012
Thursday, December 22, 2011
Wednesday, December 21, 2011
Sunday, December 18, 2011
What's going on here.....
Monday, June 7, 2010
Wednesday, February 10, 2010
Twitter is a wallflower's dream... anyone can eavesdrop and quietly judge from afar....
Last night Jesse Freeman , Ralph Hauwert and Robert Penner had a little discussion via Twitter about statics & globals. It starts here. Robert encapsulates the danger of globals with this:
Statics are evil when they puncture encapsulation and hide dependencies that impale anyone who tries to use them somewhere new.
Monday, January 18, 2010
Time To Eat My Own Dog Food
A few days ago, I posted an implementation of a Semaphore with AS3. Ever since then, something about the code just didn't sit right with me. I've wanted to research and write about the Liskov substitution principle (LSP) for a while now, and I decided that I would demonstrate it with my Semaphore classes and examples. When I first designed the classes, I thought I was doing a good job, now....not so much. In fact, I think I made errors in my application architecture and overall approach.
Wednesday, January 13, 2010
Flash does not support multihreading, and that's probably good thing since managing threads can be very, very difficult; however, Flash can have a kind of concurrency when it comes to user interface, multi-user applications (e.g. games) and synchronizing animations. With user interfaces, a developer may wish to disable parts or all of the UI while asynchronous events, such as loading assets and managing various animations are executing. Within a multi-user environment, imagine a game where players share a limited amount of resources - checking things in and out as they become available ( see 'Dining Philosophers Problem'). Another scenario might be the need to manage many, many animations.
When it comes to concurrency there are various techniques that come to mind - The Semaphore , Java's ReentrantLock and CountDownLatch, the Actor model, and Scala's Mailbox. This first post will focus on the semaphore.
Tuesday, December 8, 2009
Friday, November 27, 2009
Then....there is another theory of mine; a more subtle detail that everyone thinks, but doesn't say out loud...
Hand animated buttons are jumpy!
- If I see someone has written an event, I try to get rid of it - this goes 2x for custom events.
- If I'm working on someone's production code and I see comments, I refactor and delete them.
- I rarely use conditionals.
Thursday, September 17, 2009
Sunday, September 13, 2009
This is cool.
Computer Science guys know plenty of coding Kung Fu; for us Flashers, we have to either need some CS friends hangin' around, or discover it ourselves. This time I got lucky and had both.
Saturday, August 22, 2009
Like many other Flash developers, when I learned about creating custom events or dispatching Flash's built-in events I started doing it a lot. But..... it can really be a pain. I find that frequently dispatching and cleaning up events really dirties my code. It also makes it harder to read. Also, event dispatchers can be so far removed from methods who are dependent on them, that a coder will often have to search around to find the callback. Because of this I avoid Flash events as much as possible, and here's how I do it.
[Edit] Callbacks are also substantially faster than events: Grant Skinner's recent optimization talk
Wednesday, August 19, 2009
Sunday, August 9, 2009
Mixing Ant and FDT is simply addictive - there's just so much one can do. There are also several pitfalls that, if not prepared, can really confuse you.
Thus, I began to write down the process to aid others and to remind myself in case I forgot. Not long into this process I learned that there is a lot to cover. Instead of cramming it all into one post, I have decided to split it up among several posts.
Part one contains two videos about getting started with Ant. I'm getting back into recording videos so forgive me if I'm a little stiff. I'm getting more comfortable with recording again and I've even started doing a little bit of editing. Already between the first and second video, I can tell I'm getting better.
In total the series is going to cover work-flow tricks, working with live error checking, code hinting, templates (creating and using), how to extend Ant by adding Java libraries, FTP, SSH, ASdoc, SVN, debugging tricks, creating SWFObject swf -embeded HTML files, multi swf compilation and more.
[NOTE: This is a combination of an old blog post I did (before my database blew up) and some new stuff thrown in]
Wednesday, July 29, 2009
Fowler's article is often cited when references are made to DI. Admittedly, it's a lot to take in and consider, especially when the article gets into containers. All this can be confusing to anyone who's not a seasoned coder or just wants a simple example and not all that prose.
Tuesday, July 28, 2009
Something Between Just You and Me
There's a little secret I'd like to share... I think many object-oriented programmers use encapsulation incorrectly. For years, even I was guilty.
Yes, it's true.