Design System | Personas | JEM | Andon | Component-Based | WIE | DWI | STV | MIP | More Case Studies
eFlex System’s Manufacturing Integrated Platform (MIP)
eFlex Systems had been around for over 20 years when I started in early 2016. They had, primarily, one customer—General Motors of whom eFlex developed software for GM’s Powertrain assembly lines—engines and transmissions. One of GM’s executives took an early retirement, 
invested in eFlex and developed the next level of manufacturing software ushering in Industry 4.0 capabilities.
Whereas Industry 3.0 introduced automation, computers, and robots to manufacturing, Industry 4.0, or the Industrial Internet of Things (IIoT), is about connections. Connections between smart tools and process data, between events and actions, between user, machine and data. The Smart Factory. And eFlex was at the forefront of this. The issue was eFlex’s software was always engineer-designed for engineer users. This new software opened up to numerous users. As advanced in capability as eFlex System’s new manufacturing software was, few could figure out how to use it, even with training (unless you were an engineer). Do this here, then go there to do that, but first make sure you checked the box way over there, then come here to…
Job Element Monitor (JEM) aka Digital Work Instructions
I got hired as eFlex was launching a pilot-program for their new software at an Opel plant in Poland, Opel owned by GM at the time. My first job was to redesign a big, new feature they were presenting—digital work instructions, which eFlex designated as Job Element Monitor (JEM). JEM instantly presented assembly line operators with instructions for the particular task at hand. 
Prior to digital work instructions, these were typically laminated printed sheets in a book or loosely on a ring to flip through. Note: To update these rings and books, one would have to create or edit in an office, print, store, distribute to all locations and update local books or rings. Now, one change and the click of a button in an office, on the floor, or on a hammock in the Muldives can instantly update unlimited loctions.
I was told to design JEM with disregard to how it and the app currently looked. Assembly line operators were the primary user, but it would also likely be configured by a systems engineer. Initial user requirements included for the monitor and its content be visible from at least six feet—and in this instance, no user interaction with the monitor as it was to be positioned on the other side of the assembly line—out of reach. But, that would just be for this instance.
Seemed I pretty much had a free reign to design JEM. But free reign means designing smart and being able to justify your reasoning. First thing was to evaluate the CRUD version of JEM and the application as a whole. 
What did it do? What wasn’t it doing? Where were the obvious pain-points? Did the process flows make sense? And then how to wrangle the old design into a comprehensive and cohesive whole while moving it into entirely different design scheme? Working with the manufacturing veterans at eFlex answered a lot. A user story map unveiled unthought of items and actions.
But First, UX Goals
Simultaneously, the VP of Engineering tasked me to, as a UX Designer, set my operational goals. After an initial evaluation of the application, I reported some basic style guides first needed to be set to start getting everyone on the same page, to start establishing some consistencies, and fix inconsistencies. Personas
needed to be devised so we knew who we were developing for. It ain’t us. Pattern, and controls libraries needed to established, as well as, a custom icon library.
I am NOT a fan of Font Awesome or any public library. It’s a lot of time looking for something that kinda fits and then is simply a contrived representation. Or worse yet, thousands of designers use the same icons [along with same Bootstrap defaults], but often with differing meanings. Thus there is little visual distinction in appearance between apps. I believe an icon should be as specific a representation as can be. It doesn’t take much time to craft an icon once designed or imagined.
In addition, I reported I would like to do as much user surveying and interviewing as I could. Also, the application really could use content-driven Help. Its current Help did little than to offer an out-dated PDF of the user manual. A user would then have to search through the PDF to find the needed section… if it was even there or up-to-date. What is needed is if you are on a configuration screen and hit the Help icon—that section of Help is displayed. And lastly, develop an innovation culture. I was turned on by Thomson Reuters' innovation culture, when I worked there, who even offered 20% of one's time spent on pushing for innovative ideas and changes. At eFlex, I came to find they were already there, allowing me the opportunity to present a lot of unsolicited ideas.
Styling
I certainly needed to set some style guidelines, and eventually a design system. There were no set styles whatsoever. I surmised that one developer would create a function or screen with the libraries they knew, whereas another developer another library that they know. Being that Jira and Confluence were used at eFlex, I first created style guides in Confluence accessible by anyone—defining purpose and what elements should look like and how they should be used. I create a Quick Fix document to quickly fix obvious issues and instantly give the application a more cohesive look.
These style guides would then serve as the foundation for an atomic design-based design system—of which the developers then fashioned to create a Living Style Guide built right into the application. Everyone, new and old would be working from the same blueprint now.
JEM (cont.)
Essentially, JEM was a station monitor which listed all the tasks for a particular operation. For each task in the operation, a JPEG could be uploaded. A barely perceptible timer bar showed progress.
Original JEM minimal viable product (MVP) - 2016
Experience knowing long exposure to bright, white computer monitors was very taxing to the eyes and cause for fatigue, my initial instinct felt a dark screen was apropos for the situation. Plus it would extenuate items of importance. I also included a white background mockup 
and “theme” icon button as a possible option or alternative. Bold labels had overshadowed smaller informational data buried in color-coded pill capsules. ALL the text was too small. From six feet away, most of the text was illegible. In the data grid there was also a lot of wasted column space. This is what they were currently wrangling with in Poland.
Initially, I redesigned the UI with all the same functionality as in the initial MVP. Same elements and identifiers. Just rearranged, resized, recolored. There already was a color-coding defined of which I did like, so I further defined and utilized blue as current, green as good/pass, red as error/reject/warning. I moved the Station dropdown to the header and maintained the header for navigation and global links. The subheader I reserved for part and operational information. I made the header labels insubordinate to their content. Content is king! Labels are servants to get you to the king then should bow out—not overshadow nor constantly demand attention.
The Before MVP and After mockup - 2016
The timer bar I redesigned into a timer component. The timer bar I made circular, with big “Actual” readouts within the timer circle—large enough for a team lead to read at a glance from a distance. Below the timer ring, listed subserviently, is the “Target” time. The timer circle is green until approaches x-% of the target time, then turns yellow for warning. Going over target time the circle and its numbers turn red. When quizzed about all the empty space below the timer, I replied it will get used. (And, of course it did.)
The task listing I also maintained the original color coding, but removed the extra Step column spacing. In addition, I attached the Type icon to the Description saving more space. And for quicker reading-sake all the data grid columns were switched to flush left (instead of centered). And all the horizontal and vertical column and row lines were removed for a clean look, and an optimized cognitive load. Tasks progressed by OK buttons in the listing. Handles were placed between panels to allow the user to adjust the sizes of the panels to suit their individual needs. If data is more important, scrub the left panel wider. If the work instruction image is more important, make the right panel wider and optionally deeper.
Initial drawings
Buttons that changed the UI (e.g. Station Instructions, Compare Model) were originally at the top. I made a decision to place such action buttons within the footer. So with lots of discussion with stakeholders, some rearranging of elements a new interface was born. Being that eFlex had no specific design styles, no less a design system, and not yet knowing the best way to communicate with this IT team, I made mockups with extensive specification callouts for the developers. These would later evolve into InVision mockups for the developers.
Initially and primarily working with eFlex stakeholders, the project manager, and the product manager, I was able to get a gleaning of what this product required. In addition, there were several other major functions of the application that would need to be wrangled and woven all together into a smart, comprehensive package. Track & Trace (TnT) was like a whole separate, but attached application—and in a lot of ways treated as such. It had a bit of a different architecture that didn’t quite fit smoothly with the new. Vision was another legacy function tied in. Vision’s function was to control smart cameras like Cognex, and warehouse, search and retrieve 100s of thousands of images. OEE, Quality, and Kitting were a couple other functions not yet fully defined or implemented. Assembly though is where the heart of this Industry 4.0 application really lie. This is where all the stations were configured. This is where JEM really lies.
JEM Redesigned
The initial new JEM design was pretty much a UI job. All the MVP functions just rearranged and the interface redesigned. The Opel plant in Poland adopted it and satisfied their requirements. The Corvette plant in Bowling Green, KY was hot on this new eFlex application. eFlex soon hired a VP of Sales and a Marketing Manager to start getting the word out—and off we go! This was just the beginning for JEM. A lot more features and functionality would soon be built into JEM. What seemed like a nifty feature of eFlex's assembly software, JEM would soon become the pivot and cornerstone for pulling all the eFlex functionality together into a manufacturing platform. A lot more on these additional developments further down the line.
JEM Offline Mode
Andon Displays
"John," my boss called from the conference room, "Design me an Andon board." "Okay," I answered like I knew what he was asking for. "Siri. Andon board." Upon researching Andon boards, they are those big, ugly LED signs above the factory floor that displayed this or that data, often OEE data, but also parts built—good and rejected, or some other manufacturing-related key performance indicators (KPI). Very limited to what you can display. Did I say ugly? And very expensive?
I wondered and asked myself why an Andon board had to be one of these prehistoric, ugly, LED boards. I mean for a fraction of the cost I could buy a huge hi-res monitor and jack whatever I want on to it.
Component-Based Manufacturing, Industry 4.0 Style
About this time, eFlex got a big contract from Navistar to install the eFlex application in a new assembly line at a plant in Springfield, OH that Navistar was currently integrating to build utility vans for GM. The eFlex System driving this assembly line from a frame placed on the line to driving-out-the-door operation. 
The big challenge here was eFlex’s app had always been model-based, that is, basic manufacturing assembly—engines, transmissions. Not a lot variance. Just model variances. However, what Navistar needed was a component-based system—with LOTS of variances—model, engine, color, tires, wheels, upholstery, entertainment system, and countless options. That was more than a bit tricky. This began in late September. They wanted things to start rolling in February. We had four developers, a couple of project managers, the stakeholders and one designer, me. Off to the races.
I had a lot of configuration and process flow considerations,while at the same time learning all the intricacies of lean manufacturing, 
the intents of the eFlex application, where the app is now deviating, while brainstorming with the team to the steps forward. BUT, if we got this right, this opened up eFlex Systems to all kinds of potential customers.
Imagine!
Imagine receiving a numerical string from GM. This string represents everything for a particular build. For an individual vehicle. An abbreviated Bill Of Materials (BOM), so to speak. The eFlex application takes this string, received directly from GM’s enterprise resource planning (ERP) system, translates it to then instruct each station along the line what its tasks are for each different vehicle. eFlex then error-proofs the tasks were done correctly, collects, stores and distributes process data, then moves the part to the next appropriate station. Now, multiply that by several hundred a shift. Did I mention this had to be easy to configure too?
So, how do we make this easily configurable? What are the process flows? There are a gazillion moving parts to consider and juggle here! Lucky I work with some people who know their manufacturing grits. After lots of going back and forth we worked out a relatively easy way to manage the complexity of this task, including the ability to manipulate the build information once in the system—adding, editing, and deleting components separate from the BOM.
Long story short, several new devs got hired, some on-site, some remote. Though we hired some great talent, the challenge here was quickly and efficiently onboarding the new devs without losing the efficiency of the veteran developers. This is a very complex application to begin with, the project added much more complexity and challenges. Lots of moving parts. Onboarding landed primarily on the current, already strapped developers to bring on the new devs. They worked weekends for four months. The job successfully got done. A big hit at Navistar—a record to implement an entire new assembly line so quickly. And new ground for eFlex Systems! An honor for me to be part of such a talented group.
GEIPICS tab of the Build File Information configuration - 2017
I mentioned we were getting the build information from GM’s ERP system via an integration layer called GEPICS through SOAP. We created an interface for engineers that was comprehensive for all that was needed to accomplish this transfer—but still may have been overwhelming for some folks—especially the Complex Options Builder (COB). In a nutshell, COB is an If This Then That (ITTT) type of operation, kinda. If, for example, a common build called for a common side mirror, however, IF the vehicle also had, say, a certain luggage carrier on the roof, THEN THAT would need a certain mounting bracket added to the build. These types of edge cases had to have a mechanism to handle it. Thus the Complex Options Builder. Or, another example as shown below, building a complex component based on AND. That is common components combined together to create the complex component—if the BOM calls for a tire which is a mud tire, AND is a mud tire with black heavy-duty mud flap AND is on flared wheel wells without the gray light duty mudlaps. This then can be used again as an existing component—or combined yet with another.
Illustrated below is the Component/Options tab which fills from the BOM. The left panel lists all the components. Select a component and the right panel lists all that component's options and any complex options—designated with the EDIT button. Clicking the ADD COMPLEX OPTION footer button launches a modal with the Complex Options Builder described above.
GM and Navistar used one kind scheduling source (GEIPICS) to deliver their BOMs to us. Faurecia immediately wanted to implement this system to a new line they were integrating in Fraser, MI to build center-stack modules for some Ford SUVs. They used a different scheduling source to deliver to us. Insequence. Likely, other users yet will use yet other delivery methods. So there has to be a simple method to accommodate numerous unknowns. Back to the drawing board.
Build File Information tab for Insequence scheduling source, includes a restructured tab pattern
On a hunch, the VP of Engineering had me mockup a process and a prototype for a wizard-type of configuration for the initial set-up. He felt this was a complex page and would only be used annually, thus the user easily forgetting what has to be done. It made sense and I’ve always been a huge fan of breaking down complexity into smaller chunks. We never really did any user-testing to determine preference of one complex page or wizard, but the wizard stuck and got implemented along with the one complex, Build File Information configuration screen page, shown above.
The Engineering VP caught some shareholder flack for the time, effort, and expense into developing the wizard when there was already [the complex] build file information page. I personally feels it serves a good purpose and would like to see more such wizards implemented and offered on more such complex configurations. For power users or those it's simply understood, then yeah, direct input onto the Build File Information screen is a great option.
There were tons of other Navistar requirements that required research, collaboration, user-centric process design, configurations, and UI considerations: a REST adapter, Footprint and Sequence configuration and color scheming, PLC integration, a component-based Part Build Report, a Repair screen, a Serial Number Monitor and more. All intricate case studies on their own.
In the end, Navistar was very happy. GM was impressed. Soon after a group of engineers from another GM plant eFlex serviced was in the office to see a demo. A lot of smiles, a lot of head nodding, and a lot of hi-5s.
This opened up eFlex’s prospects in a wide-ranging way—to virtually any kind of manufacturing. This tickled the Sales team for it opened so many more doors for them. We were even getting non-manufacturing inquiries—for our process control capabilities. The Veterans Administration, who doesn’t manufacture, but they do robotic surgeries that then require precise recalibration and sterilizations approached eFlex to enforce processes and call error on improper procedure. There was also a prospect looking to instill maintenance centers around the world, using our system to implement a Primary/Replica solution to configure in one Primary location (e.g. San Francisco) and shoot out to all the Replica locations (e.g. L.A., Denver, Austin, St Louis, Chicago, Detroit, NY… London, Paris, Rome…). More on this later.
What this tech now allows is Lean Manufacturing On-Demand. That is, a customer can now efficiently order a product customized to their preferences. "Efficiently" by the click of a button and with blockchain technology, an order can automatically be created, financing established, factory order submitted, smart contracts pay an initial installment, which generates orders and payments through the entire supply chain. Upon delivery, the remainder of the payments are released.
GE Healthcare became a big, new customer installing our system in factories around the world, manufacturing such things as MRI machines, X-ray machines, and incubators amongst other high-end products. Along with Faurecia, Nissan continued with projects, and Flex-N-Gate started using the eFlex System application. And each had their own requirements that eFlex was mostly obliging. However, the big thing that Sales was saying they all want and asking for is—better work instruction capabilities. My sentiments exactly! I only need a little encouragement to start cutting loose.
The Work Instruction Editor's Text tool - 2017
The Work Instruction Editor (WIE)
Immediately upon release and use, customers and potential customers wanted more than just an image upload and some text. They naturally wanted to display their work instructions on JEM. Yeah, even if it were just those hideous, Industry 3.0, laminated work instructions. So aside of just allowing customers to import digital files into JEM, eFlex management was convinced JEM needed some work instruction building capabilities built into JEM. My role was to design such an “application-within-an-application.” “Oh yeah, and make it so the work instructions go through an approval process… oh, and someone else may need to be the deploy person… oh, what if a different work instruction shows if there is a reject…”
The Work Instruction Editor's Text tool with dynamic objects - 2018
Dynamic Work Instructions (DWI)
Using the above configuring example, let's now take digital work instructions a step further and examine the concept and execution of dynamic work instructions (DWI) more fully. The above mockup shows a dynamic work instruction as it's created in the Work Instruction Editor. Once created it's accessible to be imported into any number of tasks. And being a DWI each dark gray ring around each bolt is an individual dynamic object, as is the "Big Mistake!" text box—all hidden upon the start of the operation, but revealed or initiated by events.
At the start of, say, a Torque Task, all the invisible rings remain hidden until the current bolt is called in which a blue ring is shown on the bolt to be fastened. Or, at start all the rings turn yellow revealing all the bolts that will need torquing. Either way, when a bolt is torqued within its upper and lower limits, the ring turns green—and optionally, the value could be shown aside the torqued bolt as it does in the task list. The ring turns green and the next bolt gets a blue ring. If a torque is lower or higher than its configured limits, the ring turns red and the "Big Mistake!" banner shows. In addition, any number of other events can easily be configured—a different work instruction shows after X-minutes, a fog horn blares three times, an Andon warning light glares, the station monitor whispers in a French accent, "You're in trouble," while a hologram of Chuck Barris banging a gong appears in the aisle next to the station.
“Why are their work instructions so clean?"
At an Assembly Show in Chicago, I was wandering around, came to a booth that looked like they did work instructions. The interface very .NET-looking, dated. As I was checking out one of the videos a salesguy approached and greeted me, looked at my badge and asked, “What’s eFlex Systems do?” I replied pretty much the same as you I think. “Tell me more about your product,” I followed with. He quickly lost interest in talking to me, saying, “My guys are doing the same thing.”
“What’s that?” I asked.
“Scoping out the competition.”
I really wasn’t, but probably a good idea.
“Who’s the competition?”
“So-and-so over there across the hall… oh, and them right there, they're new.”
So I went to the booth of them right there. They had a nice looking product. And after me standing there for a couple minutes, one of the guys from the booth gave me an unsolicited, 20-minute demo. One of the founders, actually. Afterward, he looked at my badge, “What’s eFlex do?”
Later, I had mentioned to my boss and the salesguys at the booth about this competition. They had been unaware, but was definitely now on their radar—as we were now to they.
The next week during my weekly Product Review meeting, our new competitor had been a topic of discussion amongst us, most technical, but I got hit with, “Why are their work instructions so clean? I mean look how big the picture is, and just a couple big buttons…”
After the meeting I researched what I could find of their work instructions. When I found some images, it was readily apparent they were displaying only one task with just scant process information. Yeah, one task and sure the image can be much larger and cleaner. Our work instructions showed a list of all the tasks in a present operation—which is very useful to probably most users. However, some users it may be more beneficial to have a larger image. “As big as possible,” the salesguys constantly pleaded. I thought, why one or the other? ("Let the user decide," said a French accent in my head.)
JEM's Single-Task View with a Dynamic Work Instruction - 2019
JEM Single-Task View (STV)
So before the next Product Review, I designed a toggled option from the current List View (LV) to a Single Task View. The STV displayed ONLY the process data for the task at-hand, allowing me to narrow the left-panel a great degree, thus giving more real estate for the work instruction image. In addition, if the user wanted more image, a full-screen option was also included, or they could option off the timer panel. Next and Previous arrows allowed the user to go back to check a value or status from a previous task, or if needed to step forward to see the tasks ahead. All the LV features and functionality were redesigned into the STV. At the next Product Review meeting, I mentioned I looked into why their UI looked so clean and explained they were displaying only a single task. Then I showed my mockups. Blew everyone away. Its priority skipped ahead of everything, and with some minor design and configuration tweaks went right into development, and into the application.
JEM's List View and Single-Task View toggle action
We were all starting to get into the mindset of giving as much control into the hands and ingenuity of the user—with the application becoming a platform of manufacturing tools, processes and functions. Even more new customers were checking out and piloting the eFlex Systems application. Snap-on Tools, Whirlpool, Delta Faucet, Panasonic, Universal Electric, Tigercat, Komatsu, even a company that makes metal wallets. The fact that tons of process data was now easily accessible for and from all kinds of actions is very appealing.
Sales was also devising new ways to offer the application in varying levels, eventually a three-level SaaS offering.
I was involved in several Marketing meetings to mold and craft the application, and its functions into a manufacturing platform, eventually becoming the eFlex Systems Manufacturing Integrated Platform (MIP).
eFlex System's Manufacturing Integrated Platform Comes To Life
As more and more features, functions, and application-in-applications were being designed, developed, and put into production it became quite apparent we now had to nicely wrap this all up into a cohesive unit. As a marketing team (stakeholders, sales, marketing, design) we wrestled with ways to present this. Is it an app with various modules? Or checkbox features? Do we push manufacturers into a SaaS mindset and practice? In the end, it was pretty much agreed upon this was more than an app with a lot of features.
What we were putting together was actually a platform. It was apps. It was features and functions. It was tools. It was accessibility anywhere on anything—station monitor, tablet, smartphone, even a smartwatch if you want it. And it was designed for the user’s preferences. Not just user-friendly, user-centric, this was a platform to allow the user to use these tools, these functions, these apps and create workflows that suit them—not us forcing various manufacturing users to work our way.
In addition, what this platform achieved was in removing some very costly layers of the current manufacturing process—Manufacturing Execution Systems (MES), supervisory control and data acquisition systems (SCADA), very expensive programmable logic controller computers (PLC), and restrictive, legacy human-computer interfaces (HMI).
With this platform now defined, I performed a current heuristic evaluation to target all current pain points and needed fixes. My office walls were already filled with sticky note flows defining an app restructure, so I hijacked the training room walls, made printouts of all the current application pages and aligned them on a wall as the current architecture presently sat. Then I redline, marked up all the fixes needed on each screen. There was A LOT of red markups.
So, it was at this point with the transition to MIP that I felt it a huge waste of time, energy, and expense to keep fixing and adding things in the old design. We had transitioned some things to the new design first set with JEM. JEL followed that design. Andon, OEE, WIE and other new screens were designed in the new look. Modals were transferred to side-panels. A new tab pattern was implemented everywhere. All my mockups were being done in the new design. It was time for a final push!
For a couple years, it was a juggling act of maintaining the old—for quick fixes or additions—while trying to establish a new design and segue into it. But we were at the point where it was actually futile to keep fixing and adding to the old. Yeah, it really was time to break from the old.
But just saying these things is one thing and I might get agreement, but if I showed the issue and a solution it just might sail a bit quicker. The marked up prints took up a whole wall and onto its the perpendicular wall. I then took the sticky note flows from my office wall and set it up after my marked up prints. Then I designed.
The sticky note flows constituted a consolidation of loose screens or functions and configurations that were there when they should be here. Configurations spread out among several different screens and modals. 
A longtime eFlex employee and I had for a couple years discussed these changes, of what should be where—thus the sticky note flows in my office. It was there for months as a point of reference. Goal posts.
I had even at one point did a card sorting exercise among several of the employees—engineers, developers, project managers—to get some insight from these different perspectives and help decide the final UX user flows and architecture.
Original eFlex app flow
Back in the training room where my application markups and sticky notes dominated a wall and a half, I used another wall and a half to display the newly designed and architected application. A roadmap forward.
I then presented the designs and new architecture structure to the stakeholders during a Product Review. I explained the rationales behind some of the decisions. And explained this is really only a matter of some navigation restructuring in the navigation panel, a change in the header, a change in the footer and some UI tweaks would give the application much needed cohesiveness, and a nice, new look. With just some minor issues the stakeholders were sold. I wrote stories for each component, and they currently sit at the top of the Developer’s To-Do bucket. And then COVID-19.
Roadmap Design - Base w/ Sliding Panel - 2019
Nonetheless, by the time COVID came around, the eFlex Systems Manufacturing Integrated Platform was pretty solidly set. Not just with UX and UI roadmaps, but also in the way the platform was being developed—more as a cohesive whole. Also in the way marketing was presenting it, and Sales was licensing it. It was impressive. And bootstrapped all the way. Where competition was targeting huge investments to get on the field, we were there. And our customers were benefitting as well, with more parts per hour, reduced cycle times, and a marked increase in production.
Upon getting to this point, there were also numerous other features and epic stories conceived, designed, and developed:
eFlex Systems is a great place to work. No micromanagement. No looking over the shoulder while working. No harping as to when is this going to be done. No do this do that. As long as you put in your eight hours a day, made all necessary meetings, scheduling was quite liberal. It amazes me the complexity of this application and what it does. It always amazes me as to what this small group of developers (4-10) produces. Plus ownership—the shareholders—really know their domain. Each with over 20 years in real-life engineering and manufacturing.
This is probably the most laid back job I’ve ever had. Laid back not meaning doing little, but laid back in everyone knew what they had to do and did it. After being furloughed due to COVID-19, I was checking my Trello board for something—and realized I was currently juggling A LOT of stories in various phases. Four stories in To Do, a channel for items I don’t want to forget, but not whatsoever urgent. 29 Stories in the Design channel, stories I’m currently working on designing, a lot of these stories are ideas or concepts of mine being developed in spare chunks of time. 107 Stories in Review, things designed awaiting design review by shareholders. 121 Stories in the Development channel, things approved by shareholders, awaiting or in development. 261 Active stories. Plus 182 stories in the Story Done channel, these are things completed and developed into the platform.
My Trello represents my eFlex UX stories in various stages for about the last 2-1/2 years—after much of the highlights I already touted above. These are stories from slight enhancements to full-blown app-in-app epics. Most of each story—I've written the story, handled the UX and UI design, and worked with shareholders, project managers, and development—concept-to-completion. Laid-back, but certainly not idle ;-)
