You are currently browsing the category archive for the ‘Design’ category.
We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.
TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.
DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!
WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.
The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.
PierG
I’ve heard, in different moments in time, different definitions of how an IT Manager, a CIO, should look like. Which are the most important skills, the background she has to have.
At the beginning, it was all about technology:
IT was too far from human beings
and IT was available only in big corporations. The IT Manager was the guy with the white coat: an expert of her matter. An IT guy.
Than IT became more commodity and it was the time of business:
IT was too far from the business
and IT decided it was time to talk the language of the business. So the IT dept moved under the CFO or the COO, and the IT Manager became a ‘business man’. Technical skills were no more important for her: there was the outsourcing and the SLAs to cope with the ‘technical stuff’.
Then the internet came, and Google, and Facebook, and Twitter … and all of the sudden
IT, inside corporations, is too far from real life
and people inside the company use to have such a bad IT experience that he would never accept at home … even for free.
To manage all of this we need a new race of IT Managers: they must have deep understanding of both parties. They must know a lot about IT and a lot about making business. But today it’s no more enough. Nowadays IT tech skills and management skills can be an obstacle, sooner or later, if they are not enriched with good design skills.
In the innovation and design era, to move IT at the right speed (maybe 10xFaster) and at the right level of innovation, IT + management + design have to be carefully used, melted, weighed out.
PierG
p.s. Thanks to my friend Nico Bigi for the inspiration of this post
The natural tendency of most organizations is to restrict choices in favor of the obvious and the incremental. Although this tendency may be more efficient in the short run, it tends to make an organization conservative and inflexible in the long run. Divergent thinking is the route, not the obstacle, to innovation. – from “Deign Thinking for Social Innovation” by T.Brown, J.Wyatt
Amen!
PierG
This week I had the chance to listen to Prof.Vignoli of “Università di Modena e Reggio Emilia” talking about Design Thinking – Stanford d.school (+ something more 
).
One thing that I took with me from the speech is that:
“user’s need are verbs and not nouns”
Let me explain that: when you have to understand people’s needs, because you have to design something to service them, ask them to describe the need as a verb.
So I don’t need a STAIR (noun), a stair is a already a solution, “I need to go up (verb) to …” .
Got it?
I give you an extra tip for free : the most the description of the need is ‘open’ (= less constraints, more general), the highes is the number of innovative options you can get back.
PierG
p.s. Thank you Matteo for teaching me that
The future of users manuals is … no user manuals.
And what is the future for most companies is present for companies like Google.
Here is what happened to me with the new version of GMail:
A single page, the first time I use it, manual ‘in place’: easy, clean … a great pattern to me.
PierG
my goal is to share and describe a service model generation canvas that intentionally parallels the visual layout of the BMGEN canvas, but that presents ideas I wrote about in my book, Service Innovation (McGraw-Hill 2010), along with other more recent thinking I have concerning service excellence.
Briefly, I believe that a canvas specific to service models is important because most services have unique elements that deserve special attention, including the important role of frontline service providers, direct interactions between customers and the company, the inseparability of service production and consumption, and the more direct effect of corporate systems and capabilities on the customer experience.
via Service Model Generation | Service 360 Partners.
PierG
Here is another real life example after my Another (good) example of (bad) UX design.
Do you want some water? Put the glass in the proper place and push one of the two buttons over the glass: one is supposed to give you cold water, the other water at room temperature.
Now the question: which is the button that gives you cold water? The white one or the blue one? Pick your choice
PierG
p.s. And don’t ask me about the small round red button next to the glass: I’m too scared to push it!
I’ve collected some resources about “UX and friends” and I want to share them with you. I hope they can inspire or be helpful!
SEO & UX – Working together to make your site better
http://www.portent.com/blog/seo/seo-ux-working-together.htm
5 Reasons Why Metaphors Can Improve the User Experience
http://sixrevisions.com/user-interface/5-reasons-why-metaphors-can-improve-the-user-experience/
“4 UI Lessons For Instagram, From Facebook’s New Instagram Clone prsm.tc/QnviC5 via @prismatic”
- Piergiorgio Grossi
“Eyes On Pinterest: How People Look at Your Boards prsm.tc/13xqVh via @prismatic”
- Piergiorgio Grossi
PierG
I’ve collected some resources about “UX and friends” and I want to share them with you. I hope they can inspire or be helpful!
Super useful online tools to work with images
http://www.catswhocode.com/blog/super-useful-online-tools-to-work-with-images
New Design Practices for Touch-free Interactions
http://uxmag.com/articles/new-design-practices-for-touch-free-interactions
7 Basic Best Practices for Buttons
http://www.uxmatters.com/mt/archives/2012/05/7-basic-best-practices-for-buttons.php
Building a modern grid system
http://www.netmagazine.com/tutorials/building-modern-grid-system
PierG
When a SW project finish, a Project Manager is a happy, a company can send the bill and … the team moves to another project leaving the code to the lucky maintenance team.
Is the project team deeply motivated to build a product who can last for long? Is the maintenance team skilled (and willing and has the right incentive) to make the system working better and better?
Mmmm….
Here is a possible recipe:
Form long-lived teams around applications/products, or sets of features. A team works from a prioritised backlog of work that contains a mix of larger initiatives, minor enhancements, or BAU-style bug fixes and maintenance. Second-level support should be handled by people in the product team. Everyone in the team should work with common process and a clear understanding of technical design and business vision.
via Projects are evil and must be destroyed | Evan Bottcher.
What do you think?
PierG
Subscribe
