User Centred Design & its influence on the Millennial Generation

User Centred Design & its influence on the Millennial Generation

tl;dr; UCD is helping shape the behaviour of current generations because everything is designed based on the needs of the user. And that is a good thing.

Continue reading in Medium

UX Research and Scrum

UX Research and Scrum

A little while ago, I was wondering how Scrum and UX research work together. And after thinking it about for a while, plus asking friends and professionals, I have reached the following conclusions:

Two [design] principles to live by

TL;DR. Avoid the gulfs of execution and evaluation in your everyday life. Make sure you can understand that current status of the system; make sure others can understand the current status of the system after you are gone. 
One of the most influential books in my life is "The Design of Everyday Things" by Don Norman. I read it after I had finished my Master's degree in Electrical Engineering, and I changed my area of interests from VLSI analysis to Human Computer Interaction.
Coming from an Engineering with a heavy emphasis on Maths and Physics background, the book opened up a door to a completely new world, a world that I would usually dismiss. I studied my undergraduate degree at a great place but with a focus far from the human. I remember a running joke among my professors, it was that if the papers we were not reading did not have equations, then they were either on philosophy or a novel.
That book was my first glance into Human Computer Interaction. It helped me to first organise concepts that I was thinking about but could not organise in my head. Also, it showed me a lot of new ideas and concepts that I was happy to explore. And so, life passed by and I pursued a PhD and a research career in Human-Computer Interaction. Then I jumped ship and started working in the professional world as a Project Manager. And I have always found that my background in Human-Centred Design and designing for usable things has always helped me in dealing with new challenges and new situations.
There are two key concepts that have stuck with me since reading that book: Gulf of Evaluation and Gulf of Execution. How do we design to avoid those gulfs? Little by little this questions has permeated in my everyday life: from managing projects, people, teams, to even fatherhood.
A very simplified explanation of these two concepts is:
The Gulf of Evaluation: Unable to tell the current state of the system.
The Gulf Of Execution: Unable to tell how to act upon the system. 
  • Provide Feedback, 
  • Appropriate Mapping, 
  • Let people build proper mental models
  • Take advantages of Affordances

Norman describes four basic principles that can be used to avoid both gulfs:
Every time I am faced with a problem or a situation, I always ask myself: What is the current state? Which actions can I take? And after I leave, can the next person evaluate the current state? 
On my eyes, Agile Methodologies, Design Thinking, etc, are a consequence of avoiding these two gulfs. For example, Feedback and Mapping can be applied to make Work in Progress visible; and we build better mental models and take advantage of affordances by fostering face to face communication.
I just wanted to share two concepts that I have found very useful when dealing with a lot of situations when teams and people are involved. Because if I firmly believe we can make the world a better place if we design it to make it more usable if we truly follow a Human-Centered Design approach to fixing the world. 
So next time you are faced with a new situation ask yourself, can I make sense of what is happening? which actions can I take? And if I can not do it, then what can I do to make sure me, and whoever comes next, can make sense of what is happening?

The Phoenix Project: Lessons I learned

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
by Gene Kim, Kevin Behr, George Spafford

At First Glance:

I enjoyed the book, it is easy to read and it puts forward quite clearly the problems that can be faced by an IT department within the organisation, as well as the solutions to those problems.
The book remained me of "The Adventures of an IT Leader", but without the academic details at the end of each chapter.

The Book

It is an academic book, you read it to learn more about solving problems within an IT Organization. However, it is written as a story. Bill is our hero, and we follow his story after being promoted to VP of IT Operations, and all the problems he faces within the organisation, as well as the solutions he is proposing to each of them.
The book is not a great novel, so don't expect to read a gripping tale of adventure and betrayal with deep and troubled characters. But the story is a good way to get lessons across, it is fun to read and I could not help myself, but identify few characters with colleagues I have worked on in the past. Mainly because of their job role.


The book puts forward the idea of DevOps and using Lean Manufacturing concepts in an IT organisation. Whereas Scrum focuses on how to organise work within a Team, this book focuses on how to organise the flow of work within the whole organisation. Drawing parallels with manufacturing engineering. My takeaway lessons are:

  1. About Work in Progress
    1. Make work in progress visible. Make sure you know how much work is in the queue. 
    2. If Work in Progress keeps piling up, then identify and solve the cause.
    3. If Work in Progress is not flowing, then identify and solve the cause.
  2. Understand what type of work is your organisation doing.
  3. Understand how is work flowing within your organisation, and protect your key resources from overworking. 
  4. Define a clear channel of communication and avoid accepting work from unofficial channels.
  5. Work does not finish in the hand-off process, it finishes when it is being used by the end-user.
  6.  Make sure there is a clear communication among all the members involved in the work being done. Avoid the "it is not my problem and it is your fault" attitude. 
    1. Toward this end, create interdisciplinary teams.

I did not like

Applying It

  • I am smug to report that a lot of the recommendations the authors propose I implemented them while I was CIO of the City Administration of San Luis Potosi. I confess, I did not know about DevOps, but using User-Centred Design and the Agile Manifesto one can reach the same conclusions. So combining what you know, with what other people know about it, increases your knowledge, and it helps refine and improve what you are doing.
  • Using it to develop Wandr App: right one we are only focused on developing two types of work: Projects and Changes. We don't have internal projects that are independent of projects, and Unplanned work has been under control. One of the key factors to control unplanned work has been to protect resources.
  • Even though we are small, does not mean that soon we will face the problems described in the book. We are close to releasing our products officially to the public, so we need to plan for it. No point building foundations that support a skyscraper if we are only building a one-floor building; we can run out of money or time building things we don't need to release work. But, we do need to plan for it, think about it, and know how we are going to scale from one-floors to two-floors, etc. And the best way to plan and think about it, it is to have the processes ready.


A good book to learn about DevOps, good food for thought and good pointers to more resources to learn more about it. 

Internet of Things

IoT: Internet of Things

It is a world of beacons, that enrich the experience of people willing to be monitored in their tasks.

The beacon just sends its ID, like a very dumb client, to an App that actually makes of sense of it.

Is that really the idea of IoT? It opens a lot of doors, true. But ideally the beacons would also hold some computing power that would ease the load on the host.

As the world will be filled up by beacons, the UX challenge is to ease the information flow (like always) so that the person benefiting from IoT is not overloaded with information and notification.

IoT is becoming very common in marketing, but at the end is more than it. It is about learning from context, and little by little, the dumb beacon will become smarter and more hard worker.



To begin with, Martin Fowler et al review what are microservices.

The set-up: Small team developing an App, everything in Git Hub as it should be and working ok. As development grows we have more features, we are also experimenting with ideas, we need to change things. We have a branch for each Sprint, but we also start branching the sprints to play with it. When we push and merge all the branches, we need to make sure everything works again.

Microservices are, in a very simplistic way, independent programs working towards the same goal. Each service is a blackbox with inputs and outputs, each box has its own MVC. All you the service has to be is its job, it does not care what happens with the other ones. There is no core database that needs to be updated. As long as each service works properly, we are happy.

Swift and Microservices: Apple usually does not play ball withother technologies. And since one of the key features of Microservices is that it enables multiple technologies working together. The Netflix development process has been used as the flag bearer of Microservices with different technologies.

However, for me, the key aspect is just speed and modularity, and the ability to grow an app.