I worked as a UX / UI Designer & Researcher for IBM Watson Health, a subsidiary of IBM Watson. I was part of the team that developed Watson Care Manager. We provided a scalable software system, on the cloud, for healthcare agencies around the world, specifically in USA and New Zealand. I operated out of the Dublin Design Studio.
As part of a team of 10 designers, and countless engineers and business people, we developed a platform which allows a care worker to view clients and document working with that client. I have worked on a number of major components on the offering. Due to a Non Disclosure Agreement I was not able to give details about the product itself but I can be general and can tell you about my journey within IBM and what I have learned.
I applied for a job in IBM in December 2014. After going through the interview process I ended up getting the job and flying to Austin Texas. It is well documented, in the IBM world, what happens. So I’ll briefly give my interpretation of my learnings.
On the 19th of January I landed in Austin Texas for 3 months of intensive bootcamp training. Basically, if you’re a hired graduate for IBM Design you fly to Austin and spend three months being skilled and taught the IBM Design Thinking framework, a version of the Design Thinking framework. Working on four separate projects, whilst simultaneously doing classes on Design Thinking methodologies you learn how to apply the framework to projects.
These projects were used, not just to develop existing products or create new ones, but to drill into us the IBM Design Thinking framework and the importance of designing with a human centred focus. On a daily basis we would work on our projects but also partake in learning a number of different methodologies around each step of the IBM Design Thinking process, Understand, Explore, Prototype, Evaluate.
If you want to know more about the framework in general: dschool.stanford.edu or IBM Design: www.ibm.com/design. An account by a colleague which captures it well: www.100archive.com. Suffice to say I learned a lot about methods in designing and researching along with how to run workshops and collaborate with other disciplines. Putting the user needs at the core of the product has always appealed to me and this only cemented that position.
After coming back from Austin I worked on Watson Health Care Manager. Watson Health Care Manager is a Saas application created for health care workers. The foundation application is specifically for health care team members - home care nurses, social workers, psychiatric nurses, doctors, etc - to aid them in providing care for patients (After conducting research with a number of care team members I learned there are negative connotations associated with the word, so I don’t use it in a derogatory sense, but for the sake of common understanding). The platform itself is adapted for other government agencies who require similar systems.
We were a new product in the IBM portfolio, along with a number of purchased companies we had to amalgamate and merge several offerings, and this meant that the different teams needed to learn to work with one another and understand the needs of each department. In day to day work we utilises the Design Thinking framework along with an Agile approach, two week Sprints and User Stories allow for Business, Engineering and Design to merge.
I have developed my ability to generate and deliver more effective ideas, doing bursts of research to inform any design decisions. It’s interesting how working alone can cause you to converge on an idea very quickly, looking back on my portfolio and thinking about my process in general, I find that I probably didn’t spend enough time generating diverse concepts prior to IBM, there is a point when this aspect of designing is given too much time but I feel that it’s now one of my best qualities, patience in idea generation, which doesn’t mean I spend an inordinate amount of time generating ideas but rather I’m relaxed and confident enough in developing ideas, thus not getting frustrated with myself, which in itself is a conducive mentality to have when generating ideas and concepts.
Before beginning the ideation phase I like to do some in depth research, specifically talking to users of the product or people who are in line with our user base. With Watson Health Care Manager we began by talking to a range of users. Due to a tight budget and lack of understanding by the wider business and engineering team, emphasis wasn't placed on allocating a budget, initially, for research.
When posed with the need to do research without proper backing myself and a colleague decided we needed to generate a foundation of knowledge and understanding along with garner backing for future research. We reached out to family, friends and the healthcare community here in Ireland and in USA in an attempt to gain insight. Over time the wider team started to notice the benefits of our endeavour, I find it speeds up meetings, focuses the team and gives everyone a sense of confidence in what we are building, and we began to get budgets and backing. This is a short hand version of what was very much a struggle but something highly important.
Communication was the key, when doing the generative research with Home Care Nurses, Providers, Social Workers and a range of other care team member roles (who gave their time freely and generously) along with our internal IBM team. Sharing the findings and showing how they influenced the eventual designs highlighted to engineering and the business team how certain aspects of the UI design was important even though it meant doing more work to achieve a certain interaction, effect or animation.
I like to use a range of deliverables to communicate the findings, these include, Personas, Journey Maps, As-Is Scenarios, To-Be Scenarios and Affinity Diagrams, to name but a few. Along with generating these deliverables I find it important to send out invitations for team members to listen in on research sessions, share any collected images from any contextual inquiries. Basically, sharing any research findings is important, distilling the information to its core aspects is better as it makes it more easy to consume for the wider team.
When given a problem or area to look at I want to jump in and start sketching ideas. In the past, I would delay that inclination, instead developing a plan whilst also doing research. What happened was that I’d end up quelling my desire to actually diverge properly. Now I let loose and pick up my roll of wallpaper and sketch away, allowing each idea to react to the last. This sketching process actually helps build an understanding of the details. I’ll conduct primary and secondary research to understand the issue, talking to users in an attempt to capture pain points and generate a range of insights.
Once I felt I've sketched enough, and created a number of concepts to work from I’ll get onto the computer. Something like Balsamiq, it's quick and easy to create wires, and start doing out wireframes to send around to the rest of the team. This, for me, is still the exploratory stage but another way to keep the divergent momentum going. The change from paper to digital gets me thinking again and lets me generate more ideas. I start to show my ideas at this point getting feedback and maybe sparking more ideas.
Eventually I’ll have a range of wireframe options which I begin to refine in terms of concepts, thus converging. I become critical and start asking myself, more in depth, what the user would want. It is here I begin properly interacting with user research in detail, placing limitations around the initial concepts and designs. Other things which impact the design are engineering capabilities and business requirements, along with Accessibility issues and Localisation, all of which are thrown into the equation around this time of the process.
A prototype is developed, this may be by the in house Front End Developers, this may be using a Hi Fi or it may mean hooking up a flow of wires with Keynote or InVision, which are used to test - Usability and Content. Ideally we will be getting feedback from users and doing simple usability tests. Filling in the gaps of our knowledge and validating our ideas.
Once I had a solid set of wireframes and I had gotten adequate feedback we would go to our Product Managers and deliver our concepts and reasoning. There is usually feedback, sometimes this is good, sometimes this is bad, but the concerns of all stakeholders are important and a discussion is always had.
User Stories are also created, on RTC. The Balsamiqs are attached and all parties would eventually sign off, again after some discussion. Wires are taken to Hi Fi stage and Spec’d up, sent to the engineers and I will work continuously on any aspects of the product I have designed as long as that component or page is still in place. During a certain sprint the Engineers develop the wireframe into an actual working piece. As time goes by we will get feedback from tracking events and make any necessary design changes.
Usually we'd provide 100% extra space for all text. This is a major limitation and something to always being aware of when designing a international software product as German or Russian text, for example, may run twice as long as an English version.
Working with a large group of engineers based all over Ireland, India and USA meant we needed to be blatant with our designs, calling out everything and explaining the reasoning behind each wireframe. We, also, needed to work within the engineers Agile framework. As the product was new and many of the teams were also new, we were an amalgamation of several product teams purchased by IBM, all in the healthcare and analytics sector. Meaning, essentially, we needed to develop a way of working with one another, which took into account the needs, culture and time zone of each team. Best practices for Agile and Design Thinking frameworks were used, which are theoretically sound, but in practise can be too difficult to administer and maintain.
Documentation was a major aspect, in this area, which can slow down the process of designing and developing the product. It was important to document what you have done and what others have done, but there comes a point when this is overkill and has a major negative impact on teams, specifically because it takes so long to actively detail every interaction and decision. A level of start up mentality was required, one which advocates less stringent detailed documentation but promoted quicker working practices.
There are hundreds of people working on this product all with different views and ideas about how the product should be. Negotiating a design with them and within the limitations of the engineering team meant the end product may vary from the initial concept. What was important was to define the process and refine how we would present our designs and account for them within the documentation. Being blatant in the Specs and prototype was essential, being involved with engineering scrums, on occasion, was also important. This gave a level of understanding for the designer about the needs of the engineers and about how the design is being developed. It was also beneficial to have that open communication so it was not a waterfall approach, something we were keen to stay away from.
As the product was released and we were into continuous delivery we tried to stay 2 weeks, at a minimum, ahead of the engineering sprints. We had started to mimic these sprint periods, trying to develop our own design sprints. It’s difficult to do but something I feel is worthwhile trying to achieve, even if we missed the two week deadline it kept you moving at speed which is not just an efficient way of working but enjoyable.
All hallmark products needed to have an AA rating and I was well versed in Accessibility requirements. The IBM Design colour scheme is graded from 1 to 10 and any colour choices need to be made with a contrast level of 5 or more from a text perspective, so any text placed on a background needs to have at a minimum of a 5 contrast level. Text also needs to be no smaller than 11 pixels. Buttons need to be a minimum of 40 pixels on touch devices. There are a range of criteria we have to meet to pass AA standard, these are an example of some we deal with on day to day basis.