Conducting my first BA+UX workshop

The idea of the event was to investigate an internal process of business travel management and to identify existing pains and try to address them using

  • combination of business analysis and UX techniques
  • a lot of clever heads
  • prototype a possible solution

This is more of a followup to make sure the important items are not forgotten

What I did good:

  • game for group dynamics and to set the mood (marshmallow challenge with spaghetti)
  • eliciting expectations from everyone
  • getting everyone involved and active (I am particularly happy that some of the participants who I’ve not seen very active in the past felt involved and contributed)
  • got peopple interested – in the end a part of the group (3 people out of the original 6) were interested in further work and stayed after the expected closing time (6pm)
  • managed expectations more or less, 50-75% expectations were reached for a part of group (2 out of 3, 3 out of 4)
  • logistics (supplies, food, materials) – as there was a dedicated team member

What I did poorly:

  • i did not organize the knowledge exchange prior to the meeting
  • interviews were not monitored to ensure the questions were valid and to the point
  • facilitation during the training session was not quite there and there were a lot of distractions
  • managing scope of the event. the overall plan was too ambitious
  • defining the scope of responsibilities
    • there was a huge gap here as the other person who co-organized the event felt the overall idea has changed and everything should have been done differently
    • in practice very few of the original objectives have been reached need specifics here

general observations

  • this was not a workshop but more of an initiative/project ->format should have been different with the current team
    • one team doing everything end-to-end
    • many teams doing different projects
    • not one team working out using parts of the process
  • still, there are people who are interested in getting this done
  • i should have prepared better in terms of BA work
    • NOT all stakeholders have been identified
    • introduction on the matter should have been better
    • needed to focus on a smaller piece that could have been swallowed in one take
    • need to learn BPMN and EPC better to be able to quickly use those notation models
  • i need to build my team to do things like this better

Quick action list after Lviv IT Arena 2014

After the conference is over and I still remember the books/materials I should be reading soon, I’d better list them here

In terms of prioritizing the list, I think it would be as follows:

  • UML in 24h (Joseph Schmuller)
  • The mythical man month
  • The writer’s journey

then the rest

Plans for 2013

Big plans for 2013:

  • become eligible for CCBA examination with 3750 hours of real project experience and take the actual examination
  • complete three technical coursera courses (system design and need to define two more). I also need to make sure I complete Introduction to Databases this March and pass
  • take a soft skills course – communication related
  • Not really BA related but very important
  • get a driver’s license
  • put together the Eleks band thing this summer


Discovering people

As I’ve just found out, one of the chief developers in the project I work on, is quite into philosophy and even writes philosophy comics. Need to bookmark this link for future reference. This finding only makes me more certain that to be a comic, the person needs to have a highly-developed left brain hemisphere. Best jokes have impeccable logic behind them even though I love absurd jokes more. But the reason I do so is because absurd jokes appear to have a broken logic behind them and I just love things that are crooked and broken

Wizard of OZ prototyping

Reviewing the video lectures in HCI course published by Stanford professors on Coursera, I’ve learnt about the Wizard of OZ technique. The idea is that something is being shown as a functionality/feature while in reality it’s being handled/done by a Wizard behind the scene.

More information can be found here

In reality we have been using this technique very often, especially during demos. The idea is to code/implement a limited set of scenarios and demonstrate them only without a demonstration of anything not functional. The key difference is that, in the lecture the professor mentions it’s best to tell the truth and inform about the gaps at the end of the experiment but in reality this is something we don’t do.

The lecturer also compares low-fidelity vs high-fidelity prototypes. The point is to use low-fidelity at the start of the project to attract criticism and comments and eventually target to a highly usable and attractive product. Users are more reluctant to criticize or voice their concerns about flaws when something is done nicely even though it’s buggy or half-cooked