I am currently a UX / UI Designer & Researcher working for IBM Watson Health, a subsidiary of IBM Watson. I am part of the team that develops Watson Care Manager. We provide a scalable software system, on the cloud, for healthcare agencies around the world, specifically in USA and New Zealand. I operate 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 am 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 have been working 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’ve 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 will be adapted for other government agencies who require similar systems.
We are a new product in the IBM portfolio, along with a number of purchased companies we have had to amalgamate and merge several offerings, and this has meant that the different teams have had to learn to work with one another and understand the needs of each department. In day to day work we utilise 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 have a solid set of wireframes and I’ve gotten adequate feedback we will 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 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 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 means we need to be blatant with our designs, calling out everything and explaining the reasoning behind each wireframe. We, also, need to work within the engineers Agile framework. As the product is new and many of the teams are also new, we are 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 takes into account the needs, culture and time zone of each team. Best practices for Agile and Design Thinking frameworks are used, which are theoretically sound, but in practise can be too difficult to administer and maintain.
Documentation is a major aspect, in this area, which can slow down the process of designing and developing the product. It is 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 is required, one which advocates less accountability but promotes 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 means the end product may vary from the initial concept. What is important thus is to define the process and refine how we present our designs and account for them within the documentation. Being blatant in the Specs and prototype is essential, being involved with engineering scrums, on occasion, is also important. This gives a level of understanding for the designer about the needs of the engineers and about how the design is being developed. It is also beneficial to have that open communication so it’s not a waterfall approach, something we are keen to stay away from.
As the product was released and we are into continuous delivery we try to stay 2 weeks, at a minimum, ahead of the engineering sprints. We have, recently, 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 miss the two week deadline it keeps you moving at speed which is not just an efficient way of working but enjoyable.
All hallmark products need to have an AA rating and I am well versed in Accessibility requirements. Our 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.
Align your team around specific, worthwhile outcomes to achieve. Essentially these are the goals. We use the cupcake metaphor or MVP approach as it’s also called. We aim to create a wedding cake but we develop a cupcake first, test, and then move onto a more complex version, with each version building on the learnings of the last release, adding a better user experience. Essentially, if the metaphor isn't working for you, we develop a small version of the product (or minimum viable product) use that as the foundation, from here we look to develop that product further with a notion of what the best possible version.
Reflect together in a safe space to give and receive criticism. Playbacks are presentations made to stakeholders on a regular basis. The aim of these is to keep all team members and stakeholders aligned and understanding of where we are in the project and where we are going.
Give users a seat at the table. Invite them to observe, reflect, and make with you. The main aim of the design studio is to create the best possible experience for the end user. To do this we need to talk to those people who will use the product and see how the product fits into their lives and to see how we can make their working, and maybe social, better. Sponsored users are those people who use the product and give us feedback on our designs allowing us to refine them and meet our aim of developing the best possible user experience in relation to the product.