UX issues our team faced in 24 hour long hackaton from the beginning to the end. The research preceding hackaton, brainstorming sessions during the hackaton and the inevitable fall by the end of the hackaton.
I had opportunity to attend my very first hackaton in which we had to come up with interesting idea for innovation, research the idea, design it and then develop it in Agile friendly way. The word of the day was Scrum as it was the Agile methodology we were supposed to use. We had couple of days to do the research and then we had 24 hours on the event itself to actually develop it. All of this was internal involving only few departments in our company.
Properly done research
I signed up as Business Analyst. Researching the field, deciding on purpose of innovation, the meaning and reasoning was all my responsibility. As was the design of the innovation.
We already had basic concept: ToDo list which would improve the work for teams using Scrum. Idea owner wanted his personal ToDo tool that would help him during stand up meetings. I felt there is a lot of ToDo lists already and as I had few days heads up on this I conducted few research interviews to determine the biggest problems in Scrum environments when it comes to ToDos, tasks, stories and so on.
From my interviews I learned of many issues, but most of them could have not been solved by any kind of software. The problem was simply in the culture of the company. There were big gaps in time zones between various team members which made it pretty difficult to communicate and cooperate. When one went to sleep, other just woke up. Communication relied on one mail a day, waiting time for response was way too long. This was the main issue of almost every team.
But I manage to uncover something else, something software related. Almost every team was using the same tool for task management. Tool they did not like that much. Every review of the tool started with how difficult to use it was. Leaders of the teams had to run educations for every new member on how to use the tool and the actual developers reported lots of inconvenience and bugs in the tool.
And so I had idea what to do. Creating simple ToDo list as the idea owner wanted became possible innovation as long as it would synchronize with this 'not so liked' tool and simplified its control.
Imagine it this way: If you like the old tool, continue using it. If you don't like it, here is a new shiny one. The tasks synchronize among them so whatever option you chose, you won't lose any already done work. Basically, our simple ToDo list wasn't just another tool which people would need to learn, it was now an extension / a replacement of the old one - to some extend at least.
Poorly done research
And so we had clear idea what to do. Well, not that clear, but good enough. Did not take long for us to hit the first wall. So in what way is our interface better? Well it is easier of course and it brings new features. Actually, no. It is not that much easier and it does not bring any new features.
What I failed to do, was to do actual research into the old tool. See how it works and how it feels. I worked with it little bit. Although only on newly setup projects, but never on in progress projects. My task list was empty. Teams I was designing tool for had their task lists full.
And as I started noticing how the tool looks when filled with content, I started to panic. It had all the features people needed. We even started to brainstorm cool ideas how to improve the interface, only to realize, such features are already there, we just never thought about using them.
Maybe that was the thing we improve, make it more obvious, let people know these features are there. But in the end, this entire idea started to feel wrong. So our development hackaton started with us realizing, we have no idea what to do.
Innovation vs time constraints
One way of fixing this was to actually build some features that were not in the old tool. Something new and fresh, some bug fixes and so on. Making it simpler to use for the developers. There were things we could fix and so we started to think about them. Until we hit the wall. We had 24 hours and what we wanted to do would require so much more than that. We simply did not have enough time.
And once again the panic started. What to do next? Should we just create the simple ToDo list which idea owner wanted despite the fact non of us believed in it? It would just be another tool people would need to use and there is lots of others performing the same role. It would be us reinventing wheel, not innovating it.
Or should we try to make as much as possible, knowing that we would barely scratch the surface of the tool we would like to have by the end of the day? And so we argued. Until we came to conclusion that we can do both. Kind of.
We would start with the simple tool. When done, we would try to populate it with some randomly generated data and pretend it is synchronized with the old tool. And if we managed to do that, we would actually try to look into API of the old tool and connect it.
This would mean, we would not really implement any new features and we would not innovate that much at the end of the day. We would create the very simple basic idea of ToDo list. There would be only one difference with all the other ToDo lists - ours would be connected to Scrum tool used in almost all of our teams.
Hopeful start, Pitiful end?
At the end we managed to get it done. We create the ToDo list, we generated some random data and we found our way around API of the old tool. It seemed like stars aligned. And with this great amount of luck on our side, sleepless night worth of effort and some pizza, we created our first prototype version.
It displayed tasks. That is it. There was not even option to add or edit them yet - at least not working. And so we were triumphed by the very simple Notepad we all love from Windows. Since in Notepad, you can at least edit the stuff.
Was it worth it? I would say yes. We did not succeed in creating innovation in 24 hours but we managed to create the basic block for the later success. We now had the basis for actually extending the old tool and building upon it by creating new interface which would simplify the interaction with the data in it.
There was even notion to continue working on it after the hackaton, to get it done because it could really help people. It could be useful and meaningful. If that happens will remain mystery for now. One thing that is a fact is that our product by the end of the hackaton was not really worthy of that much attention.
After all, we had pretty high hopes for only 24 hours of work. On the other hand, all of us learned something new. I learned once again, the importance of good research and planning. Definitely something that I will keep messing up in the future till I finally get it right.
Post a Comment